Does my segwit node only have segwit blocks? My segwit node makes a gettxout RPC query and checks the scriptPubKey.type is "witness_v0_keyhash" and does things accordingly.

To my understanding old nodes have different blocks and if I happened to fetch a block from an old node, what will my node do? Will it simply store it as is and ultimately result in not getting the desired "witness_v0_keyhash" response when I expect?

BIP 144 equipped nodes doesn't fetch blocks from old nodes since they are only capable of providing witness stripped blocks.

If someone sent it a stripped block (e.g. by lying about their support or whatnot) and it contained any segwit using transactions then it would get dropped and the peer disconnected-- basically treated like merkle tree malleability.


Able to send 0.2BTC from old to new wallet w/o fee as of 2016? Good evening everyone. I've been out of the cryptocurrency scene for a couple of years and I've stumbled into a minor issue. I've been trying to figure out if it will be viable to move some Bitcoin from one wallet I own to another without a fee. Specifically, I'm trying to send 0.2BTC from an Armory wallet to an Electrum wallet (latest stable versions of each client).  The 0.2 BTC is all I have in that Armory wallet at the moment and I'd ideally like to get it to Electrum intact if possible and thus without fee.

When I try to send at 0 fees with Armory, it warns me I need 0.00012407 "for the size and priority" of the transaction. I am not sure how it calculated this or if it is a baseline estimate (which is pretty close to the default 0.0001 fee.), but it will allow me to send at 0 against its advice.

Reading over the description of how transaction fees are calculated my transaction seems to miss some of the "gotchas" that the protocol requires a fee (ie 0.2 BTC is not small enough to require fees),  the coin itself is definitely old enough as the transaction that granted it to me was from 2014 and I haven't moved it from Armory since then etc.. but when I read over a variety of articles and posts there is a lot of variety in the confidence that such a transaction would be actually be validated sans-fees.  Some older posts from 2013/2014 don't seem to be of use any longer, as it seems that transactions were more likely to be processed without a fee back then compared to now.  Others suggest that at the value I still shouldn't have much trouble or to just give it a try and see

So given the current state of Bitcoin in 2016, should I attempt to send the 0.2 BTC to myself without any fees and have a reasonable expectation of timely (within a few days ) processing?     Should I send without fees and my transaction goes unconfirmed for days, what would be the best way to "cancel" it and try again?  Is there another way around the problem that I've not yet considered?

Thank you in advance

0.2 BTC to myself without any fees and have a reasonable expectation of timely (within a few days ) processing?

There are no miners today who confirms free transactions.


What cryptography hardware and/or software does a bitcoin exchange need to employ? We have an operating equities exchange. To exchange bitcoin or other crypto-currencies, what cryptographic hardware or software would we have to use?

An exchange does not necessarily need their own hardware, as they won't be mining anything. However you will defenitely need some hardware.

A server

Where else do you host your exchange? Your laptop?

A dedicated device for cold storage

Every good exchange needs a cold storage wallet, to ensure that if you get hacked, you won't lose all your funds.
-A cold storage wallet is basically a dedicated device that has never touched the internet. This is very effective against malware, as there is no way for malware to access your computer unless the actual hacker has access to your device.

A dedicated device for your own node

You defenitely don't want the guy hosting your node to fake an incoming transaction and get you to credit them with free funds! Host your own node that will not be tamlered with.


Would it really be this easy to steal peoples bitcoins? I was just looking for an Ethereum wallet app for Android, and something hit me.

Could someone create a wallet app for Android/iOS that simply pretends to create a wallet address but really just displays the address of the one who created the app, causing the victim to transfer his/her funds straight to the app creator instead of their (supposedly) newly created wallet?

This seems too easy...

Yes, of course this would work.

What do you expect? It's the digital equivalent of walking into a random building with a storefront that vaguely looks like a bank with lots of dollar signs, and then asking "hey i want a bank account, where do I send money?".

Don't install random wallet software. Do research.


How much would it cost to do a 51% attack how much would it cost to carry out an 51%-Attack?
If there is a place service in the web that you can rent ASIC's than i would rather hear what renting this would cost. If not then buying the asics is fine too.

To keep the calculation KiSS following assumptions:

Attacker chooses the cheapest way of renting/buying hardware. But he is NOT renting/bribing whatever the existing machines from miners from the existing bitcoin network. The gear has to come from outside the network.
Don't worry about that renting/buying such a huge qt would drive the price for the hardware up.
Ignore what the community would do, the cored devs or whoever to counterstrike your attack.
you don't need to include electricity cost in the calculation. If you do include it, please tell what you took for US-Cents/kw/h

Thank you!

P.S. is there a website that does this calculations on a regular basis? Would be cool to check this from time to time..

Update 4 Years later ond June 2019: The Hashrate of the Entire Network is right now (according to Bitinfocharts.com): 55,42 ExaHashes. Most efficient Miner is the DragonMint which has exactly (and realisticaly) 16 TH/s and costs including with power supply 2844USD. One would need 55 420 000 TH/s /16 TH/s =3,46 millin Dragon Mints * ~ 2800USD (included a small rebate)~ 9,8 billion USD. Crazy how the cost increased in the last 4 years from 145 Million to almost 10 billion...

EDIT X Years old answers to this question don't matter at all. This question needs to answered every 6 months. Entirely new generations of Asic-miners, change picture a LOT

There is a handy chart at https://en.bitcoin.it/wiki/Mining_hardware_comparison.

If we assume that it is complete, and that the figures listed there are accurate (I have not verified them), and that the attacker must buy the hardware, then the most economical device is the Antminer S5+, which produces 7.7 TH/s (7.7e12 H/s) and costs US$2300.  It draws 3.4 kW.

The current network difficulty is about 5.6e10.  This means that an average of 5.6e10 x 2^32 = 2.4e20 hashes are needed to mine one block.  Assuming that one block is mined each 10 minutes (600 seconds) on average, the network as a whole is producing 2.4e20 / 600 = 4.0e17 H/s.

So a 51% attacker needs to produce about 4.0e17 H/s himself, to match or slightly exceed the hashing power of the existing network.  This means he needs 4.0e17 / 7.7e12 = 52000 Antminer S5+ devices, which would cost 52000 x $2300 = $120 million.

(This is unrealistic in a couple of ways - buying that many devices would not only drive up the price but probably exceed the production capacity.  On the other hand, such a large order might qualify for a quantity discount or wholesale pricing.  This attacker might also find it more efficient to license the design and do the manufacturing themselves.)

Running these machines would consume 52000 x 3.4 kW = 177 MW of power.  If the attacker is located in the US, this table shows that the cheapest place to get electricity at an industrial rate is Washington State, where it costs an average of 4.5 US cents per kWh.  At this rate, the attack would cost US$8000 per hour to supply with electricity.

If they are all to be located in one place, there will be additional costs to build / rent and operate a facility to house them all, with appropriate electrical infrastructure.  There will also need to be significant network and server infrastructure to connect them all to the Bitcoin network.  Cooling costs will also be substantial - Google says that their data centers have electrical overhead of about 12% (i.e., on top of the electricity used by the equipment itself, an additional 12% is used for cooling, power supply losses, etc).  They say that the industry average is more like 70%.  You would also have to hire an IT staff to maintain everything.

This overhead might be reduced if the devices were to be distributed (e.g. each of 52000 people keeps one in their house) but then you start to incur administrative costs to keep all those people organized.  (Just picture the communications department to tell them what to do, accounting to make sure they all get their cut of the proceeds from this evil scheme, human resources to recruit new participants, etc.)


Is the current Bitcoin implementation easy for different users to participate in a single transaction? I read a paper from 2013 (Androulaki E., Karame G.O., Roeschlin M., Scherer T., Capkun S. (2013) Evaluating User Privacy in Bitcoin. In: Sadeghi AR. (eds) Financial Cryptography and Data Security. FC 2013. Lecture Notes in Computer Science, vol 7859. Springer, Berlin, Heidelberg) that, regarding transaction input, "currently, Bitcoin clients do not provide support for different users to participate in a single transaction; to achieve this, users would have to modify the Bitcoin client implementation themselves".
What about now?

Also am I correct that most of the transaction nowadays have still only one user as input?

Sources (to ex. papers) would be nice.

The referenced paper is from 2013. It may have been true that at this time it was difficult, to share a spending activity amongst users. This link here https://gist.github.com/gavinandresen/3966071 explains the details around multisig, and comes in early 2013. As of today, you got it correctly, we have multisig in two variants, and the statement doesn't hold true anymore.
On the aksed sources: there was a paper from 2014 (http://www.quantabytes.com/articles/a-survey-of-bitcoin-transaction-types), that evaluated the distribution of transactions type, but that is the last I know of... and I haven't seen any updates since then.


Why do wallets of Bitcoin exchanges have tens or hundreds of thousands of addresses? I am looking to track the wallet of Kraken and see how the balance changes at each block.

For that purpose, I use www.walletexplorer.com (https://www.walletexplorer.com/wallet/Kraken.com/addresses) and I can have access to all the addresses of Kraken's Wallet. For now we can see that there are 114 458 addresses.

My questions are:

Is that number fix ? (I doubt so)
What those addresses represent exactly ?
Why do we find so many addresses but only around 20 of them are rich? (others are very close to 0)

I imagine it like every customer of Kraken is associated to one address (so that's why we find so many addresses) and all these addresses are managed/held by Kraken. But I am note sure.

Thank you for enlightening me.

Is that number fix ?

It isn't. New addresses are generated by exchanges all the time.

  What those addresses represent exactly?

They are simply multiple addresses controlled by them. They can represent addresses the users deposit coins too (often one per currency, so BTC and USDT may have separate addresses), or intermediary addresses used for consolidation, or hot wallets, or cold wallets, or temporary addresses used as change addresses.

  Why do we find so many addresses but only around 20 of them are rich?

In general, exchanges tend to have thousands of user addresses, into which users send crypto. Exchanges will then move all that crypto to a handful of hot and cold wallet addresses, which they will then use to process use withdrawals. The majority of addresses will be empty most of the time, unless you happen to check one between the user depositing coins and the exchange sweeping it to a consolidation wallet.


Reveal a result after block height So imagine we have 5 different parties, all of these parties test if a particular thing is true or false over the course of 24 hours. The network needs to come to a consensus about the majority outcome of these parties votes. So the 5 different parties need to submit their votes onto a blockchain, however if within the 24 hour time-frame one of the parties submits their vote early there comes potential for one of the other party members to look at the early submitted vote and copy that vote skewing the real result.

What is the way to prevent copying in this situation, can a hash time locked contract be opened that collects the encrypted votes from each party and then after the 24 hours reveal the result to the network?

Or is there something simple im missing, the basic idea is I want to cryptographicaly hide something and then reveal it at a certain block height

I cross posted this question on another forum and revived the below answer

  The security of these systems tend to depend on the precise set of behaviors that should be allowed. You may be able to find a simpler system, depending on the behaviors. For example, it may make more sense to have the 5 provide cryptographic commitments for their vote during the 24 hour period. Then, when 5 commitments are seen or 24 hours has passed, each one reveals their vote. This handles the specific issue you mention of skewing the results, but does demand that the parties broadcast 2 messages at different times, rather than just one message.

From this i consulted with a few other people can came up with the below which should work

  Each of the 5 parties could publish Hash(vote || random bytes), because of the random bytes it would not be possible to find the vote by hashing guesses. Then after all commitments are published or 24 hours has passed each party would publish the plaintext = (vote || random bytes), and all other parties could hash that to verify that it is equal to the original commitment.

This solution is elegant in that it relies only on the parties participating to reveal the information


Are there statistics on how Bitcoin holdings are spread among addresses? I'm aware an address can belong to multiple people, and one person can have multiple addresses. Still, I'd like to assume the number of accounts per person is O(1) on average.
Are there statistics on how much the bitcoin holdings are spread between different addresses - in other words, on whether a few addresses hold a large portion of the bitcoins, or rather is it spreading out slowly?
Ideally I'd like to see a graph of this "measure of spread" over time.
Related Questions
Is it possible to estimate the Gini coefficient for Bitcoins and if the trend is increasing or decreasing?

I don't know if any of this data is of any use or significance, but...

I calculated the Gini coefficient at the end of each month of Bitcoin's history.  I did it in two different ways:

The vast majority of Bitcoin addresses that have ever been used are now empty.  They don't represent the "have nots", they're just addresses that have been used and discarded, and so shouldn't be included in the calculation.  Similarly there will be lots of addresses which are holding change from transactions.  I arbitrarily decided to throw away all addresses with a balance of less than 1 BTC for this first calculation.
Then I calculated the Gini coefficient for just the 100 richest accounts at the end of each month.

The results are shown below, with the columns in order:

the date.  "Jan 09" means "the end of Jan 09"
the total number of addresses in existence at that date, including empty ones
the number of addresses with 1 BTC or more in them
the amount in the richest account
the amount in the 100th richest account (notice how this stayed at 50.00 for over a year)
the Gini coefficient of the >= 1BTC addresses
the Gini coefficient of the top 100 addresses

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 09       2,569     2,439     2775.00 -   50.00   0.04571   0.50862
Feb 09       5,975     5,642     9075.00 -   50.00   0.05064   0.71354
Mar 09       9,444     8,864    16675.33 -   50.00   0.05794   0.82048
Apr 09      12,893    12,120    21175.33 -   50.00   0.05715   0.85527
May 09      16,288    15,380    26675.33 -   50.00   0.05306   0.87075
Jun 09      18,528    17,534    30675.33 -   50.00   0.05118   0.87980
Jul 09      20,456    19,338    36675.33 -   50.00   0.05248   0.89165
Aug 09      22,021    20,741    44473.86 -   50.00   0.05617   0.90351
Sep 09      24,180    22,639    53974.86 -   50.00   0.06188   0.91664
Oct 09      26,311    24,366    61424.62 -   50.00   0.07208   0.92725
Nov 09      28,533    26,403    61424.62 -   50.00   0.07279   0.93164
Dec 09      32,611    29,818    61424.62 -   50.00   0.08352   0.92241

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 10      37,647    34,333    72374.36 -   50.00   0.08571   0.92339
Feb 10      43,329    37,262    72374.36 -   50.00   0.13683   0.88570
Mar 10      48,615    40,316    72374.36 -   50.10   0.16674   0.82492
Apr 10      57,806    42,661    72374.36 -  500.00   0.21059   0.71037
May 10      63,368    44,583    72374.36 -  630.00   0.24448   0.65747
Jun 10      69,540    46,963    72374.36 -  750.00   0.26638   0.62843
Jul 10      94,992    51,628    72374.36 - 1757.14   0.32583   0.56689
Aug 10     107,172    53,578    72374.36 - 2100.02   0.35365   0.52483
Sep 10     120,562    53,492    72374.36 - 3000.00   0.39915   0.46956
Oct 10     135,952    54,637    85000.00 - 3333.33   0.42841   0.46050
Nov 10     155,639    55,756    90000.00 - 4150.00   0.45464   0.43790
Dec 10     176,326    57,247    90000.00 - 5000.00   0.47592   0.38625

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 11     210,243    58,073   250000.00 - 5350.00   0.49987   0.47440
Feb 11     267,542    59,699   250000.00 - 5650.51   0.52439   0.47584
Mar 11     353,093    61,984   250000.01 - 5613.86   0.54646   0.45504
Apr 11     443,112    64,254   200000.00 - 6002.81   0.57161   0.46808
May 11     631,480    70,883   297000.00 - 6309.40   0.62830   0.49247
Jun 11   1,061,590    90,159   424242.42 - 6308.24   0.70803   0.52602
Jul 11   1,548,806   101,895   384587.42 - 6450.00   0.73473   0.50905
Aug 11   1,930,979   105,572   104895.01 - 7495.92   0.74448   0.41533
Sep 11   2,205,926   106,973   105000.00 - 6926.85   0.74847   0.45014
Oct 11   2,411,298   110,463   105000.00 - 7345.73   0.75422   0.44981
Nov 11   2,601,999   111,386   455501.30 - 6926.85   0.76065   0.51328
Dec 11   2,768,500   118,263   105555.00 - 6705.00   0.76137   0.41685

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 12   2,956,869   123,003   105555.00 - 7000.00   0.76883   0.42408


sent BCH to a BTC Segwit address Is there a way to recover the BCH ?

Use his Ledger purse
I've sent BCH
To address BTC Segwit
This link is treated
https://explorer.bitcoin.com/bch/address/36CU6nDniJca1UVhvNhjsDdZpUsyYw5vSx

I want to get it back BCH

Not without help of a BCH miner.  Basically there is no way to claim these coins under Bitcoin Cash since they unpicked all the SegWit changes prior to forking.

These coins are actually seen as "anyone can spend" coins on the BCH network (unlike in Bitcoin, someone claiming these is breaking no rules so the transaction would be accepted as valid), so a miner can claim these for themselves, if you find a good one, then you could politely ask them to claim them and forward them onto you.


Why are brain wallets not secure? People keep saying it, but explain to me why? Everyone keeps saying brain wallets are insecure. Can someone explain to me WHY?

What if I had a brain wallet that is 200 characters long which is the concatenation of all of my family members names along with punctuation's and numbers? How about that?

And how long is a private key? I don't see how a brain wallet is insecure if you come up with something ONLY you can know.

It's not to do with length, but entropy. Humans are terrible at creating randomness, even what you think is hard to guess could in all probability be guessed with enough iteration.

Family names for example are easy to guess, there's a finite number of them and a vast portion of names are from a set of only a few hundred.

What's the chance of you remembering what names are, the spelling, punctuation and ordering? Fairly low I suspect, humans are also terrible at remembering explicit data like that.

As soon as people start trying to be clever, the probably shifts from theft to irrecoverable loss. Just use the cryptographic keys the way they are supposed to be used, 256 bits of entropy created with a CSRNG.


Slush's pool worker offline I'm new to mining, and using GUI miner on windows 7 AMD APU A-Series. I set it up today, put in my username.workername and put in stratum.bitcoin.cz as the host, and 3333 as the port. It says I'm getting 2 MHash/sec, but when I go to the Slush's pool website it says my worker is offline!

Can somebody please tell me what I'm doing wrong?

At this point 2 TH/s is ok for small miners, 2 GH/s is crazy slow and 2 MH/s is probably not enough for the pool to even detect that you are mining at all. So that's most likely your problem.

Even the best gaming computers had to give up in 2013. Mining is now done on ASIC hardware. Computers are just too slow.


Having trouble solo mining I mine for fun. Please no responses saying "You really shouldn't mine on that computer. At all. Forget mining exists."

Whenever I try to mine using the instructions given in the README of the GUIMiner, it gives me an error as soon as the bitcoin.exe launches as a server.

Here's the error:

Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).

Try changing it to rpcallowip=192.168.0.0/24. Wildcard support was removed from bitcoind, more on reasoning here:

https://github.com/bitcoin/bitcoin/pull/4102

rpcallowip=192.168.0.0/24is CIDR notation that is functionally the same as 192.168.1.*.


what is the "Banlist" (Bitcoin Core) Upon start up, after it has downloaded and verified the blocks, the Bitcoin Core client "loads the banlist". What is this banlist?

It is a blacklist of erroneous nodes' IP addresses which has accrued a certain amount of banscore due to "misbehaviour". To check what sort of erroneous behaviour is considered "misbehaving", you can check the Core source code.

It is a precaution to protect your node against potential denial of service attacks. Example actions which will accrue banscore includes spamming "mempool" messages, relaying invalid transactions/blocks, etc...


How is a transaction fee transferred? I know that for a mining reward, a (special?) transaction is included in the the block (in the merkle tree I believe?)

But how is a transaction fee payed out exactly?

Is this also a special transaction?

I would imagine the sender of the transaction has to then also include an extra transaction to pay out the fee?

I know that for a mining reward, a (special?) transaction is included in the the block (in the merkle tree I believe?)

Yes, the so-called coinbase transaction that sends (currently) 12.5btc to the address of the mining node/pool/etc.

  But how is a transaction fee payed out exactly?
  Is this also a special transaction?
  I would imagine the sender of the transaction has to then also include an extra transaction to pay out the fee?

The fee is payed implicitly and it is not a special transaction. Each transaction has some inputs (addresses) and some outputs (addresses). The transaction fee is equal to: inputs value - output value. e.g. if the inputs are 1btc in total and sends to outputs a total value of 0.9995btc the remainder of 0.0005btc is payed as a transaction fee to the address specified in the coinbase transaction (miners address).


green addresses are "generally considered a bad idea and not advisable to implement."? Why does the wiki say that green addresses are "generally considered a bad idea and not advisable to implement."?

Green addresses has receivers trusting the owners of the green address to not perform a double spend. However trusting anyone to not double spend in Bitcoin is inadvisable, regardless of whether they are actually trustworthy or are a corporation. Even if you do trust that the owner of a green address will not perform a double spend, double spends can occur by accident due to implementation failures (writing a wallet is hard).

There is also no guarantee that a transaction "from" a green address (note that there really is no such thing as a "from address" in Bitcoin, you don't actually send from addresses) is not guaranteed to confirm, even if no double spend occurs. The transaction may have too low of a fee to be confirmed in a reasonable time, and may even be low enough to be evicted from nodes' mempools if it remains unconfirmed for too long. There may be third parties performing transaction malleation attacks on those transactions resulting in malleated transactions being confirmed instead of the one that you expect.

In general, using green addresses means that you are trusting unconfirmed transactions which are not guaranteed to confirm. Double spends are not the only risks with accepting unconfirmed transactions, there are a variety of other things that could result in an unconfirmed transaction never confirming which the owner of the green address cannot control. As such, it is inadvisable to use green addresses.


import multisig wallet into bitcoin core, Vpub keys are not valid. how to? I'm trying to import an HD multisig wallet created with Electrum into Bitcoin core v0.21.0.0.
I managed to do so with the fantastic cryptoadvance.specter server, but I also would like to import it using the standard bitcoin-cli commands.
This is what I managed to do so far, and it only works if I convert the pub keys Vpub Multi-signature P2WSH to tpub P2PKH, so for example:
Vpub5fRxfoprsHS9Vnhq1grZcJrWSRmSeBZbLCbnTJcvSDXr3xoBurx8MUt8UmHCsTVPXqk1rNpgt3X3KAvcJzCZvwn9yQymrWhwMJpEYysLqQV
becomes
tpubD8a2g9FwJxvC3c7YBvwvQL35Ph7jJTN4PnarTPCJAND6HGXSizk4ew1JxWKgqLXZuZSZ6KXZTFfgem2ar1itGNUywE1XJTY9azG4WBr25hn
then I can run this program and it seems to be working fine, unless it's not because the resulting addresses are very different. (the wallet created with Specter matches perfectly the one in Electrum, it finds the correct transactions as well)
#!/bin/sh

wallet=$1
pub1=$2
pub2=$3

echo "Making wallet '${wallet}' from ${pub1} ${pub2}"

rawdescriptor="wsh(sortedmulti(2,${pub1}/*,${pub2}/*))"
descriptor=$(bitcoin-cli getdescriptorinfo $rawdescriptor | jq -r '.descriptor')
bitcoin-cli deriveaddresses  ${descriptor} "[0,0]"

bitcoin-cli createwallet $wallet true
bitcoin-cli -rpcwallet=$1  importmulti '[{"desc": "'$descriptor'", "internal": false, "range": [0, 1000], "timestamp": 1609459200, "keypool": true, "watchonly": true, "label": "lol"}]' '{ "rescan": true}'
# bitcoin-cli -rpcwallet=$1 rescanblockchain

I can't use the Vpub keys because bitcoin-cli (v0.21.0.0) throws this message:
key 'vpub5UXsYa6RJKsn5DYT52PanEWhidjBRpt11vx7Y3MP4ShSRnEH9TZrGN2Cg4KjK2GVJNg2ynpZzq8YC1Jr1m3cnTfV8wsNT7EwTaYMy4PCDAg' is not valid.

At this stage i’m only interested into a watch only wallet, so i don’t need to use private keys.
Also, I'm in testnet and I have testnet=1 on my bitcoin.conf
I've tried reading as much as I could but I think i hit a wall now and I don't know how to continue.
Any help would be greatly appreciated

this is a script that works for me, it imports a 2of3 HD multisig wallet.
I have very basic knowledge of bash so you may want to double check it before running it, anyway, what finally worked for me was to understand that I had to wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))to derive the receive descriptor and wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))for receiver.
I also found this good converter here:
https://jlopp.github.io/xpub-converter/
#!/bin/sh

wallet=$1
pub1=$2
pub2=$3
pub3=$4
startfrom=$5
range=$6

wallet="${wallet:=test}"
pub1="${pub1:=Vpub1...}"
pub2="${pub2:=Vpub2...}"
pub3="${pub3:=Vpub3...}"
rescanblockchain="${startfrom:=1934907}"
range="${range:=[0,100]}"

p1=$(echo $pub1 | cut -c1-10)
p2=$(echo $pub2 | cut -c1-10)
p3=$(echo $pub3 | cut -c1-10)

printf "\n\nWorking on '${wallet}' from ${p1}... ${p2}... ${p3} starting from ${rescanblockchain}\n\n"

# create wallet if needed
if [[ $(bitcoin-cli listwallets | jq '. | index("'$wallet'")' ) == "null" ]]; then
    echo "Making wallet '${wallet}' from ${pub1} ${pub2} ${pub3}"
    bitcoin-cli createwallet $wallet  true
fi

# convert keys format from vpub to tpub https://jlopp.github.io/xpub-converter/
pub1=$(node converter.js ${pub1})
pub2=$(node converter.js ${pub2})
pub3=$(node converter.js ${pub3})

# get descriptor for receive addresses
raw_receive_descriptor="wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))"
receive_descriptor=$(bitcoin-cli getdescriptorinfo $raw_receive_descriptor | jq -r '.descriptor')

# get descriptor for change addresses
raw_change_descriptor="wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))"
change_descriptor=$(bitcoin-cli getdescriptorinfo $raw_change_descriptor | jq -r '.descriptor')

# import receive addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$receive_descriptor'", "internal": false, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# import change addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$change_descriptor'", "internal": true, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# rescan blockchain
bitcoin-cli -rpcwallet=$wallet rescanblockchain "${rescanblockchain}" | jq .

# just print out few receive addresses
bitcoin-cli deriveaddresses  ${receive_descriptor} "${range}" | jq .

# print out balance
bitcoin-cli -rpcwallet=$wallet getbalance


Extra security for paper wallets I want to transfer my bitcoin to a paper wallet for long term storage. However, with the risk of fire/theft etc. I'm not comfortable holding it as a paper printout.

So my question (sorry if its too noobie)....why not:

1) create the paper wallet addresses

2) manually write the public and private keys on a piece of paper BUT for the private key, change just one character of the key in a way only I know. For example, increase the 4th character of the key by 1 (so if the 4th character was the number 8, I write it as a 9 on my piece of paper, if it was the capital letter B, I write it as the capital letter C.....you get the idea). So far so good for having a secure paper storage. But what about fire etc...

3) Email the info to my gmail/hotmail account. So I'll always have access to the info as its stored on "the cloud" but is hopefully useless to anyone who hacks my email??

Is there a flaw in my system? Is potentially giving my public address plus 95% of my private key to would-be hackers risky?

Many thanks for your thoughts!

This is extremely risky and not a good idea.

If you just increment one character, there are only about 50 ways to do that.  It would be extremely easy for an attacker to just try all 50 possibilities, and they would find your key and steal your coins.

Even if you change one character to a new random character, that's only 50 * 58 = 2900 possibilities.  Still very easy.  Particularly since the key has a built-in checksum, so that an attacker can tell with high probability whether their guess is correct with a simple computation.

The security of your private key rests in the fact that it is a random one of an extremely large number of candidates.  By revealing most of the key, you reduce that number of candidates to a very small number, and lose all your security.

Don't reveal any part of your private key, or save it where attackers could get it.  Also, don't try to "encrypt" it with any scheme you come up with by yourself (e.g. a substitution code) - those are also extremely easy to break for any reasonably clever attacker.


How did Ripple handle DoS/DDoS during the ripplescam.com days? I'm going to assume that during the days where Ripple was irrationally hated by some sub-population, a la the ripplescam.com site which used to be the first result on Google for "ripple coin" until Ripple set the decentralization plan in motion, that it was mercilessly DoS and DDoS attacked.

How were/are the servers protected?

OK, since the comments section is starting to get unwieldy, I'll type a longer and slightly more elaborate answer, that incorporates some parts from the answer by @VinnieFalco.

According to Wikipedia, a DoS attack is defined as: "an attempt to make a machine or network resource unavailable to its intended users" and it commonly involves "saturating the target machine with external communications requests, so much so that it cannot respond to legitimate traffic, or responds so slowly as to be rendered essentially unavailable"

We all agree that a system that is connected to the Internet and is offering a service at some port cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

There many "types" of DoS attacks, but they all boil down to one thing: they seek to consume resources:

As you know, resources come in many forms; sometimes attacks will consume bandwidth, other times they will consume RAM, disk space, IOPS, file descriptors, license slots/seats, or just about any finite resource that your service requires.

Fundamentally, you have two options: either increase available resources above the level of the attack, or ride it out.

Sometimes you can do a little better: you can attenuate an attack that seeks to consume bandwidth by using a content-delivery network. You can go from rotating hard drives to flash-based storage, and even to RAM based storage if the attack causes I/O performance to drop. You can limit the use of commands that require resource under attack.

Sometimes you can do better still: you can detect that the attack traffic comes only from a subset of hosts and filtering those data streams off at an upstream provider. If I/O is a bottleneck, you can attempt to rearchitect code to reduce the amount of I/O necessary. If commands are computationally expensive, you can attempt to optimize them or even reimplement them in a more efficient manner.

But, ultimately, all you can really do is blunt the force of a DoS attack. Generally speaking, you cannot prevent a DoS, and if it hits, you usually end up having to buckle down and waiting for it to pass.

So what about the Ripple servers?

As far as increasing the available resources, obviously that's outside the purview of the code: it can't magically provision more resources. That's the job of server operators who will typically ensure that their servers have sufficient excess capacity to provide servers even when demand for service spikes. So this isn't anything the code can do about something about.

What the servers can do something about, however, is to attempt to detect when they are under heavy load or attack and respond to that. In a sense, both those scenarios play out the same:

The servers will penalize connections which are forcing the server to do more work per unit of time than the server considers reasonable. Typically the penalty is to inform the user that the server is too busy and to ignore the command and to disconnect him if he persists in issuing commands at an unacceptably high rate.

Of course, the server has no real way to distinguish with perfect accuracy whether a user is abusive or not because it doesn't have a crystal ball. All it knows is the commands that it receives from a source and the rate at which the those commands are being sent and it bases its decision on that. So while this countermeasure will affect users who are, indeed, abusive, it can also affect legitimate users.

The server can also track load across all its connections and can decide to make some commands (which it knows are very expensive but not strictly necessary) temporarily unavailable, as load begins to climb. In that way, the server can conserve resources to use in processing the commands which are necessary.

Of course, this approach is more blunt and will affect legitimate users, as the server may refuse to execute an expensive command even from a legitimate user  who has not issued any other expensive commands nor caused undue load.

On top of that, there's what Vinnie Falco mentioned: the servers seek to protect themselves and the network from abuse by:

Imposing (miniscule and neglible) transaction fees that are payable in XRP and which scale dynamically in response to various factors, including network load; and
Imposing network-wide 'account' and 'action' reserves.

This means that someone seeking to attack the network in certain ways must, in essence, pay for the "privilege" of doing so and they harder they attack, they more they must pay.

Why is this helpful? Generally those who are orchestrating a (D)DoS attack don't really have to pay and their costs are minimal, making the attack not only  cheap to launch but cheap to maintain as well. This is a huge advantage

By imposing fees, which, for regular users are negligible, Ripple servers and the network take that advantage away: they "prevent" (D)DoS attempts because the cost of launching and sustaining an attack against Ripple quickly adds up.

There are a few other mechanisms which Ripple servers implement to protect against and mitigate the effects of (D)DoS attack. Combined, all these things work pretty well, but the bottom line is that we have come full circle to what I said earlier:

A system that is connected to the Internet and is offering a service cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

One other thing I didn't touch upon: Optimizing the Ripple server code to improve performance. This is something that we at Ripple Labs spend a lot of time on and we still have things we want to do and ideas we want to implement. We also hope that the vibrant community of talented open-source developers will take a look and contribute their many great ideas as well.


Is history reversal a concern if the absence of attackers is assumed? As described in the Bitcoin paper, the Bitcoin network may temporarily diverge, or "fork," as nodes may work on different blockchains.
The network reconverges, however, as a node will always continue working on the longest blockchain it learns about.
This opens up the network for history reversal, since transactions that are part of a discarded blockchain might not be part of the longer, universally accepted one.
This is typically discussed in the context of an attack scenario.
E.g., many vandors wait for a transaction to be confirmed six times until accepting it as payment.
This is presumably due to the Bitcoin paper stating that, assuming an attacker controls 10% of the network's processing power, waiting for six confirmations puts the attacker's success probability in the order of 0.1%.
However, in a scenario that assumes the absence of attackers, would there still be the need to wait for some number of confirmations?
After all, history reversal is an intrinsic part of proof of work -- facilitating network convergence -- even if it is not abused in order to double spend, right?

Yes, there is still a need to wait for confirmations.
Even in the absence of active attackers, there are many reasons the Bitcoin network could diverge, such as:

Large scale internet routing issues - we've already seen these with BGP routes being incorrectly broadcast, leaving large chunks of the internet temporarily inaccessible from other large chunks. In such a scenario, if miners are isolated into one of the two groups, each isolated group will advance the network without any visibility into the blocks being produced by the other side until the two networks are merged
Implementation bugs - although Bitcoin nodes generally just run Bitcoin Core, different implementations of the same Bitcoin Protocol can occasionally result in consensus bugs that result in everyone on one implementation rejecting blocks from the others. This has resulted in a few forks on other chains with multiple common implementations, such as ethereum.
Just normal mining - the very nature of mining means that sooner or later, two miners will produce block N simultaneously. This results in a split chain until the next block is mined, at which point only the block that is included in the prevBlock for the new block is retained.


Private key to mnemonic words, is it safe? Is it safe to do the following?

Suppose I do not want the HD wallet, but I do want the convenience of using mnemonic words to remember the private key. I know I can convert the private key's hex representation to byte format from which I can get binary format, from there I can follow BIP-39 to generate 24 words that are represented by that private key (because general addresses are used by randomly producing a 256 bit word which is equivalent to 24 words). Can I now use these "mnemonic" words to remember my private key, and completely disregard it (since I can always use these words to get back to the private key). I guess what I am wondering is whether there are cases where different private keys can produce the same collection of 24 words.

Here are two mechanisms for converting a 256-bit (64 hexadecimal  characters) seed into a Electrum seed word mnemonics, and back again.

#1 JavaScript-based

#2 C++ - based

However, the command line interface example below, using mechanism #2, uses one of the most unsafe private seeds is used for demonstrative reference purposes only.

1% echo -n "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | ./bytes_to_words

rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper

2% echo "rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper" | ./inverse_mnemonics

0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

The results are repeatable using mechanism #1.

BIP 39 doesn't require invertability support (analogous to ./inverse_mnemonics for Electrum words) albeit it can be accomplished. See How to generate a valid hash for a bip39 seed phrase? for an approach for accomplishing this task.

The mapping back to the BIP 39 root seed in hex is guaranteed to be unique. However, due to normalization associated with ed25519 cryptography, not currently used by Bitcoin, it is possible to have multiple two sets of 25 Electrum words that map to the same functional private key.


How can I follow the progress of miner signaling for Taproot activation during the Speedy Trial deployment? How can I follow the progress of miner signaling for Taproot activation during the Speedy Trial deployment? Can I use bitcoin-cli to track the signaling progress?
This was asked by pox on Mastodon and has been paraphrased.

Hampus Sjöberg has set up a site (https://taproot.watch/) with a graphic for which blocks have signaled for Taproot activation and a breakdown by mining pools. It was announced here on Twitter.
AJ Towns stated on Mastodon that once signaling starts the Bitcoin Core RPC getblockchaininfo will report the number of signaling blocks in the current period.
David Harding added on Mastodon:

If you want to implement checking yourself, you can use
the versionhex in either debug.log or the results of getblock.
Taproot is using bit 2.  See the versionbits FAQ for details about
bits:

pox also wrote an awk script that I haven't tested.
gawk -F'[= ]' '/UpdateTip/ { print("block="$7" taproot="and($9,2)) }' <~/.bitcoin/debug.log

If you are interested in which mining pools have already indicated that they will be signaling readiness for Taproot activation see taprootactivation.com.


What is the purpose of the script like RETURN PUSHDATA(36)(...) The example is in here:
https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0

Actually, there are two outputs
DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG
and
RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]

The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.

There are two questions about this transaction.
1) How the coinbase could have more than 12.5 BTC?
2) What is the purpose of the RETURN PUSHDATA(36)(...), actually, in theory, this output can never be consumed by anyone, becuase there is no OP_CHECKSIG or similar OP at the end to return true in the Script stack.

1) How the coinbase could have more than 12.5 BTC?

Because of transaction fees

  2) What is the purpose of the RETURN PUSHDATA(36)(...),

The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.


Block.io set smaller fees? Is it possible to set a custom transaction fee with block.io? We are using their API and their "Low" fee is still far too high (currently $3)

I really don't suggest to use block.io since they will limit your number of your bitcoin addresses.

Any way they don't support custom fee.

As on block.io site

  Estimate network fee will be paid on withdrawal of given amounts


GPU support on cgminer and bfgminer I just read this answer which states that GPU mining support was removed from cgminer as of version 3.7.2.

Does anybody know what version of bfgminer needs to be used to support GPU mining.

I am currently using bfgminer 3.8.0. On Mac OSX 10.8.5, with an Intel HD Graphics 4000 GPU.

The version you are using is the latest version

It supports OpenCL GPUs.

Which includes Intel HD Graphics 4000.

There is no information of Bfgminer discontinuing GPU support anytime soon.


channel count differs on my site and 1ML I wonder why:
lightning-cli getinfo;listfunds

{
  "id": "035aef5661e1a6e370db60dc0455796800afd5b51fbc12a0a8b34836b15f5d7ef6",
  "alias": "TWronald✅",
  "color": "15c315",
  "num_peers": 41,
  "num_pending_channels": 3,
  "num_active_channels": 38,
  "num_inactive_channels": 0,
  "address": [
    {
      "type": "ipv4",
      "address": "220.133.223.206",
      "port": 9735
    }
  ],
  "binding": [
    {
      "type": "ipv4",
      "address": "0.0.0.0",
      "port": 9735
    }
  ],
  "version": "v0.6.3rc1-118-g0da4054",
  "blockheight": 563691,
  "network": "bitcoin",
  "msatoshi_fees_collected": 82538
}

157278 satoshi available to fund channels
7318449 satoshi owned in channels
19485999 satoshi total channel capacity
---------------
Total funds: 7475727 satoshi
Percentage of total channel capacity owned: 37.5575
---------------
Add command line parameter [B] for BTC, [m] for mBTC, [y] for microBTC, [b] for bits and nothting or anything else for satoshi
by Rene Pickhardt.
Consider a tip: via curl -i -H "Accept: application/json" -d '{"amount":ENTER_AN_INTEGER_AMOUNT_OF_SATOSHIS_INSTEAD_OF_THIS}' http://ln.rene-pickhardt.de/invoice

On 1ML.com:

Capacity
0.19280979 BTC (0.027%)
$751.22
Channel Count
37 (0.132%)
Connected Node Count
37 (1.120%)

Rene, I tried to send you some thanks, but it should be https and even then it didn't work.

Since 1ml is not open source I can not give the exact reason. But some things are known that add to the discussion. The information about your node that you get from getinfo or listfunds are accurate and up to date.

New channels have to be announced over the gossip protocol so it will take some time until 1ml is aware of your most recent channels. This is one certain reason for the difference.

Another reason is that 1ml does not see your private channels since they are not announced over the gossip protocol. This could be the reason if the difference exists for a longer time.

Also it seems to me from my user experience from using 1ml that 1ml does not update its info in real time but does some batch processing (this part is speculation as their software is closed source) anyway this could also slow down the process of updating your node info.


Get public or private key from address with C-lightning I'm studying Lightning network and I use c-lightning.
I can Get a new address with newaddr method, but I can't find private key.
My address is bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrg, how can I retrieve it's public key?
Where Can I find it's private key?
$ bitcoin-cli validateaddress bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrgj                                                              │
{                                                                                │
  "isvalid": true,                                                                                │
  "address": "bcrt1qmckts70jsq2u5886lgcq2yn7xjmp97t09zlrgj",                                                                            │
  "scriptPubKey": "0014de2cb879f28015ca1cfafa3005127e34b612f96f",                                                                       │
  "isscript": false,                                                                                │
  "iswitness": true,                                                                                │
  "witness_version": 0,                                                                                │
  "witness_program": "de2cb879f28015ca1cfafa3005127e34b612f96f"                                                                         │
}

lightningd doesn't offer simple RPC commands to dump keys.
If you really need to access the keys the simplest way would be to derive them directly from the hsm_secret.
Keys for onchain transactions (since you mentioned newaddr. The other derivations are more involved) are derived using BIP32 unhardened derivation from m/0/0.
The root seed is derived from the hsm_secret with :
root_seed = hkdf_sha256(hsm_secret, salt=NULL, info="bip32 seed")

There exist tools such as the hsmtools (which currently only derive keys for the commitment transactions but might be extended in the furure) or jb55's clightning-dumpkeys which take care of the derivation for you.


What is the User Activated Softfork (UASF) proposal? How do its risks compare to hardforks? The Bitcoin community is abuzz with discussion about shaolinfry's proposal of a UASF to activate SegWit as an alternative to the Version Bits activation. I've seen frequent and extensive discussion of the proposal and especially questions about the risks and advantages of it compared to other methods of softfork activation and hardforks.

What does the UASF proposal entail?
How do its risks compare to other methods of upgrading the protocol?

What does the UASF proposal entail?

The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected.

BIP148 is an instance of the UASF proposal that implements a UASF for SegWit. The idea is to have the economic majority, users and businesses, run software that forces miners to activate SegWit. If miners do not start signaling for SegWit by the proposed time, their blocks and the bitcoins mined within will be invalid. In this sense, it is a hard-fork for miners, but a soft-fork for most full-node operators.

A soft-fork usually undergoes the IsSuperMajority process, where miners do not start to enforce the new rules until 95% of the last 1000 blocks signal readiness to enforce. This is usually just for coordination, so that miners are in agreement about exactly when the new rules become enforced. Of late, however, miners have been using this process to block the SegWit soft-fork from being enforced at all. Many believe that miners should not be able to block soft-forks, so the UASF was created to remove that ability from miners.

  How do its risks compare to other methods of upgrading the protocol?

A UASF may transition to be enforced before miners have updated their software to support it (typically this would be intentional on a miner's part, as the activation date would be chosen very far in advance). In this case, that miner may be mining invalid blocks, according to the rest of the upgraded network. If a large portion of the network has upgraded their software to enforce the signalling for the soft-fork, but a large portion of the miners do not agree to signal for the support of the soft-fork, then a chain fork may occur. Non-mining nodes would see very slow block generation times and the transaction backlog could grow. Mining nodes would produce blocks, and bitcoins within, that are not acknowledged as valid by exchanges and users, rendering their mined bitcoins worthless if they do not upgrade.

This situation would create a stand-off between economic stake-holders and miners. For upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them. For miners, a chain-split means they are creating bitcoins that exchanges and users will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog. Users and exchanges already cope with low transaction throughput and high block solve times due to normal variance, whereas miners currently have nearly 100% of their blocks accepted by the network. So I suspect the miners would be the first to give in and start signalling support for the soft-fork they don't like.

However, a miner may produce a block which signals support for a soft-fork without actually enforcing the new rules imposed by the soft fork. This may conceal the lack of consensus temporarily, for as long as the produced blocks follow all the rules of the new soft-fork. As soon as a block is produced that does not satisfy the new soft-fork rules but is still valid according to the old pre-soft-fork rules, there would be a chain split with the same stand-off dynamics mentioned before.

UASFs also rely on getting a large portion of the network, especially large economic actors such as exchanges, to upgrade. If this does not happen, and the miners do not start signalling support for the new soft-fork on their own, then the minority of nodes that did upgrade risk forking onto their own chain with no miners on it. This may cause outages of some bitcoin services, but since the bulk of nodes and miners are supporting the growing chain, there would at least be consensus on which chain is valid. Upgraded users would have to downgrade their software to return to consensus with the main chain. In this case, the UASF fails.

But who decides whether a soft-fork has enough consensus to warrant a mandatory activation time? Shaolinfry has this to say on this topic:

  There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident. [Source]

So UASFs could be used to attempt to force controversial or potentially harmful updates, but enforcing the UASF activation time would require the majority of the network to upgrade, so this may be seen as a relatively small risk factor.

In short, UASFs are more risky, but may be deemed necessary when miners refuse to support soft-forks that have the backing of the economic majority.


Can I pass values over a bitcoin bip 70 URI? is it possible to add arguments such as BTC amount to a bip 70 URI, something like:

bitcoin:?r=http://127.0.0.1:8000/paymentobject/?amount=10

I already tried with the backwards compatible URI:

bitcoin:?amount=10&r=http://127.0.0.1:8000/paymentobject/

But the client doesnt seem to register anything other than the 'r=' param.

Any help greatly appreciated :)

EDIT:
Added function from django views.py for extra explenation-

def protoresponse(request):
    xpo = payments_pb2.ParseFromString(request)

    returnaddress = xpo.Payment.refund_to
    transactions = xpo.transactions
    memo = xpo.Payment.memo

    xpa = payments_pb2.PaymentACK
    xpa.payment = xpo.SerializeToString()
    xpa.memo = u'success, i think'
    return HttpResponse(xpa.SerializeToString(), content_type="application/octet-stream")

Note, the function is defined as protoresponse because we have optional string payment_url = 6; in the payments.proto file.

The purpose of the BIP70 is to provide a secondary URL, which, when visited by your client wallet, will provide all the details to make the transaction, and a whole lot more. It was designed to be linked to POS systems which would generate the information and produce a unique URL.

In the standard Bitcoin URI scheme, it is possible to pass the amount, but you also need to pass the pay-to address.


Is it possible to have a modified Proof of Work that does not require as much energy to secure the blockchain? As more ASICs hash away for acceptable difficulty, the difficulty keeps rising over time. Greater difficulty means to me that more electricity is used to secure the Bitcoin blockchain. Are there clever ways to modify Proof of Work, continue to use existing ASICs, spread block extraction to more miners, and continue to secure the blockchain without increasing power requirements? I'm not interested in other algorithms like Proof of Stake, Proof of Burn, etc.

No, because by design PoW is assigning relevance proportional to power usage.

If the market pays N USD per day worth of BTC to miners (in subsidy + fees combined), then the mining ecosystem will converge towards spending N USD minus profit margins. Not all of those costs go to electricity (as there are also employment and hardware costs from failure and depreciation), but a significant fraction of the costs do go to power.

It is absolutely irrelevant what the actual PoW function is, from this perspective.


Blockchain shows a confirmed order still "unspent". How do I reclaim Bitcoin thru Coinbase, so I can place order again I placed an order thru Coinbase using Bitcoin to the address the vendor provided at checkout, and the transaction was confirmed.  However, now several days later, the Blockchain shows the Bitcoin "unspent". I never got the confirmation email from the vendor.  If the vendor doesn't spend it, due to a loss of the order or wrong wallet address, will Coinbase refund my Bitcoin, so I can try to place my order again?

When a transaction output is labelled as "unspent" it means that it is still available for spending. Assuming that the transaction output went to your wallet, it means that your wallet still has that unspent available for spending.


Where can I get a list of all the 72 initial NXT stakeholder addresses to see distribution? Where can I find a list of all the nxt accounts that were the initial 72 seeders? I want to find out to see how many of these accounts have moved their funds and dispersed it to the public.

All 73 initial stakeholder accounts are included in the genesis block of the blockchain.

You could write a script to extract the detailed information you are looking for from the block chain, using the NXT API. However, even if you follow the money trail, there is no way to know who owns the destination accounts -- some may be owned by the original stakeholders.

Perhaps a more useful study is to analyze the blockchain to determine the amount of NXT concentrated in large accounts vs. small accounts. This has been done in a graph here. Notice that much distribution took place during the first month or two and continues at a slower pace since then. You can click along the horizontal axis to remove selected bands in the graph.


Help understanding OP codes on multisig redeem script (hex) I was reading this gist and am not sure I am understanding/reading the hex of the multisig's redeem script correctly (line 14). It is:

52410491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f864104865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8722084861c5c3291ccffef4ec687441048d2455d2403e08708fc1f556002f1b6cd83f992d085097f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d4621353ae

So I see the three public key pairs, beginning in bold text. I understand that the last byte (0xae) is OP_CHECKMULTISIG. But I am confused about the bytes (0x53, before 0xae) and the 5241 at the beginning. I am under the impression that before the public keys there should be two variables pushed onto the stack; one because of the checkmultisig bug and another to identify the m of n required signatures to unlock the bitcoin. And then n should come right before the last opcode (3 in this case).

What am I not understanding correctly? What's up with those fives and the 41 at the beginning? Thanks for the help!

Link to gist if broken: https://gist.github.com/gavinandresen/3966071

You are on the right track. 0x52 and 0x53 are the multisig elements ("2 of 3"), and 0xae terminates the structure. The "off by one error" comes before the signatures, which is in lines 58-60 of the gist. A good explanation of the multisig is (of course) in Andreas' book "Mastering Bitcoin". I have decoded the structure below:

    52: OP_2:                the number 2 is pushed onto stack
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        0491BBA2510912A5:BD37DA1FB5B16730
        10E43D2C6D812C51:4E91BFA9F2EB129E
        1C183329DB55BD86:8E209AAC2FBC02CB
        33D98FE74BF23F0C:235D6126B1D8334F
        86
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    139FpKh63Vn4Y73ijtyqq8A6XESH8brxqs
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        04865C40293A680C:B9C020E7B1E106D8
        C1916D3CEF99AA43:1A56D253E69256DA
        C09EF122B1A98681:8A7CB624532F062C
        1D1F8722084861C5:C3291CCFFEF4EC68
        74
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1PNvbXZFysxvx3252w9JHMa7zbG95snqnm
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        048D2455D2403E08:708FC1F556002F1B
        6CD83F992D085097:F9974AB08A28838F
        07896FBAB08F3949:5E15FA6FAD6EDBFB
        1E754E35FA1C7844:C41F322A1863D462
        13
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1jqo3ptYSnUhCJq75MMyRuwC2zNyQqRy3
    53: OP_3:                the number 3 is pushed onto stack
        ##### --> 2-of-3 Multisig
    AE: OP_CHECKMULTISIG:    terminating multisig

        corresponding bitcoin address is:    3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC


Does bitcoin provide non-repudiation? Bitcoin defines you need to sign the previous hash and the destination public key. By doing so, you assume that you transferred the money. That provides non-repudiation of the transaction to a given key pair.

If you used bitcoin to buy "guns", how can the court legally prove that you, a person, are the owner of the key that made the transaction?

Since the key is not certified by a trustable third-party, you can't prove the association between the key and its owner. Am I correct?

If you used bitcoin to buy "guns", how can the court legally prove that you, a person, are the owner of the key that made the transaction?

The Ross Ulbricht/DPR trial provides several examples of how you might prove that someone made a transaction:

Being the person who sells the product or service to them. For example, the "hitman" Ross hired to kill Curtis Green was actually an undercover agent.
Grabbing the laptop used to make the transaction out of the hands of the guy who made it, and forensically analyzing it.
Other ways, like having a confidential informant, (like Curtis Green) or getting them to plead guilty (like Carl Mark Force.)


How to backup paper wallet digitally I'd like to move some bitcoin off an exchange and into a paper wallet for long term storage, but looking for ways to backup the keys in case of theft/fire/stupidity.

My thought was to (on a new offline machine) create the wallets and put the keys in a text file, as well as print. Encrypt the text file with GPG and record the passphrase in my password manager and on the paper wallets themselves.

Is it reasonably secure to then copy and store that encrypted file on USB, Dropbox, email etc?

I wouldn't use Dropbox. Use 2 encrypted USB drives or harddisks and store both on separated locations. Storing it on 2 locations prevents it to be damaged during a fire or any other event or robbery.

The precautions to take depends on the value of your wallet ofcourse. A high value means higher precautions.

For example, you'd store $30 cash in your wallet and $1.000.000 or gold bricks in a safe or trusted bank with goverment insurance.

If you have a $xxx or $xxxx amount, store an usb at your home and another one at your work. If the amount is higher, i'd spend some money on a safe.


Why is scriptSig filled with scriptPubKey before signing a transaction? I'm checking the transaction signing as described here Redeeming a raw transaction step by step example required.

What is the reason for steps 5 and 6: temporarily filling scriptSig with scriptPubKey of the output we want to redeem?

Can't this just be skipped, as with txid and output index we uniquely specify the output thus scriptPubKey and we don't get any value with this filling?

There seem to be no reason: Ken Shirriff's blog explained it this way:

  Then the signature is turned into code in the Script language,
  creating the scriptSig script that is embedded in the transaction. It
  appears that using the previous transaction's scriptPubKey during
  signing is for historical reasons rather than any logical reason.[17]

and the link points to a thread from 2013:
https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257


How can I limit the mining to specifics miners authentified by private key or something like that? I know how to code in C++, but I don't know really how all mining system works.
I have my altcoin, and I would like to block reward blocks to miners which are not authentified (something by private key or Wallet Address).
I would let miners generate blocks and coins, but I don't want them they get it, all coins mined for nothing would be sent to a master wallet or be lost forever. But, if a miner has generated coins and he is authentificated and authorized to generate coin, he would get them.

To put it simple, I just want to block coin generation ability to everyone.
I've thought I could just stop them to run a thread for mining, but they could modify the client and start it.
So I was wondering how can I can do that, I've read the code about CheckWork, ProcessBlock, etc...
But I can't understand it fully.

Thanks from advance for your help.

I'm not sure I see why you'd want to do it (increased centralization, likely decreased anonymization, and decreased mining incentive are generally considered bad things), but here's how I think I would do it, in general terms.

Have one (or more) master public keys hardcoded into the app. Have a special type of transaction that must be signed by a master's private key that authorizes an address to mine. Only blocks that have a reward, with the reward paid to an authorized address are considered valid. The address-authorization could exist in the same block that it's mined in, or any prior block in the chain.

(optionally) Allow blocks with no reward.
(optionally) Have another special type of transaction that authorizes
a new master key, to try to ensure that you won't be left without
valid masters in the future.
(optionally) Make the authorization limited by time and/or number of
successfully mined blocks, so that it must be renewed periodically.


Question Regarding Send_to_many function of blockchain wallet api I am using send to many function of blockchain wallet api and i am facing issue.

when upto 20 transaction done then after i get error in terminal that

1538652825520 - error: ERR_PUSHTX

1538652826930 - error: ERR_PUSHTX

and until that upto 20 transactions get 1 confirmation on block i am unable to send any other transaction from that wallet and it's specific address.

i want to use sent to many function for sending unlimited transaction from one wallet to my site users bitcoin addresses when they submit payment request from their account.

kindly help me regarding this.

Thanks

What you need to manage is the fee rate. Bitcoin core nodes will not relay transactions (or include them in blocks) below the minimum fee rate of 1000 satoshi/kB (-minrelaytxfee), so if you keep increasing the transaction size, but not the fee, you risk not getting relayed or even mined (-blockmintxfee), since miners typically maximize the fee rate in the block being mined.


How do transactions leave the memory pool? How does my bitcoin core client know when to drop a transaction from the memory pool?

Is it as simple as a specific period of time?

As of Bitcoin Core 0.14.0, these are the ways a transaction can leave the mempool:

The transaction was included in a block.
The transaction or one of its unconfirmed ancestors conflicts with a transaction that was included in a block.
The transaction was replaced by a newer version (see BIP 125).
The transaction was at the bottom of the mempool (when sorted by fee per size), the mempool had reached its size limit (see the -maxmempool option), and a new higher-fee transaction was accepted, evicting the bottom.
The transaction expired by timeout (by default 14 days after entering).

Also, transactions that have left the mempool can always enter them again. For example, when they're part of the local wallet and get rebroadcast, or when they're received again over the network. Eviction does not imply a transaction is cancelled.

Since Bitcoin Core 0.14.0, the mempool is saved to disk, so it persists across restarts. In earlier versions a restart would also result in a wiped mempool.


Economics article on BitCoin I was wondering if some economists started to create a research group around BitCoin, or published academic paper on it. In general, I was wondering how BitCoin was analyzed and studied in academic research.

Currently, it seems, most of Bitcoin-related published research are of technical and legal nature (according to Google Scholar, Mendeley, Bitcoin Wiki).
While there is some economical analysis performed by community (wiki, this question), I haven't managed to find any papers in peer-reviewed journals.

This discission on Quora explains some of possible reasons for this. Excerpt from top answer by Erik Madsen:

  Overall, Bitcoin is a fine example of a currency market, but it hasn’t
  (so far) told economists anything new about how the world works. It’s
  not surprising that most research on Bitcoin is from a cryptography
  standpoint, because that’s really the interesting part of the whole
  endeavor.

and his comment on another answer:

  Private currencies are no longer common, but they have existed.  And
  the intentional opaqueness of the market, and it IS quite opaque,
  means that its utility as a data source is severely limited.


What is the meaning of the field for "Profitability decline per year" in bitcoinx' profitability calculator? In the Bitcoin mining profitability calculator at bitcoinx.com/profit, there is a field with the description "Profitability decline per year". What does this field mean in regard to the calculation?

At a guess, I'd say, if it's set to 0.01 the projected income for a year from now will be 1% of today's projected income.

I agree that it isn't worded very well. It seems to be a number r such that the revenue n years from now will be r^n times the revenue today, so basically what you said.

To empirically verify this, set electricity and hardware cost to 0 (so that profits equal revenue), time frame in months to 12 (for a full year), and profitability decline to 1. You should get $1,366 or so. If you change it to 24 months, you get $2,732 - exactly double the previous. On the other hand, with a profitability decline of 0.2, you get $679 in 12 months and $814 in 24 months, which is $135 (or 20%) more.


How did the first 50 Bitcoins come into being? How was the Bitcoin system initialized? Can one start the system with only a single node (computer)? Please explain it in plain English. Thanks, guys.

The first block is known as the "genesis block" or "block 0".  It was mined using the same hashing algorithm as any other block, but at difficulty 1.  It contains only one transaction, the coinbase, which gives 50 BTC to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

Once the block had been successfully mined its hash was hardcoded into the Bitcoin client's source code so that it and it alone would be accepted as the official genesis block.

src/main.cpp contains this line:

uint256 hashGenesisBlock("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f");


What are the key differences between different ways of embedding messages in the blockchain? Are some possible ways to embed messages in the blockchain better in some sense than others? What are the important differences?

(Followup on this answer)

There are multiple places one can embed messages in the block chain. Any field that takes arbitrary values can be used.

Nonce - nonce is a field in the header that can take 4 bytes of data. Not the best place to embed much, but it does not bloat the block size
Coinbase string - probably the best place to embed messages. It takes an arbitrary length and doesn't have to adhere to any rules. Main problem is that there is only one coinbase string per block, which usually means one would have to mine the block oneself in order to encode the string. Another important thing to note is that one should not use the exact same coinbase string all the time, as it might make the output irredeemable (if the transaction hash is duplicated)
Transaction outputs - The Tx message outputs can be used to encode messages in the form of output addresses and possibly Bitcoin transfer amounts. This can create irredeemable transactions (if the transfer amount is higher than 0). The overhead of encoding transactions in this way is not too big, in case of 0BTC transactions it would be 10 wasted bytes for about 23 bytes sent (total transaction size is about 33 bytes).
Transaction script - Probably the best way to encode messages, although it is not widely supported (requires custom transaction script creation). Messages are created by adding two script operations - OP_PushData and OP_Drop in the output script of any transaction, and adding the message body in between the two operations. In order to embed messages in this way one would add just a couple bytes in order to send fairly large body of text.

One could also try creating partial SHA collisions that would encode to some short message, although this method would require a lot of computing, yielding short message encoding.


What happens if I spend a double spend? Given I can receive a double spend and potentially re-spend it after 1 confirmation, what happens to that transaction once the double spend is detected during a blockchain reorg?

A transaction's input parameter has to include the outpoint (txid and vout) of the transaction from which you have got the bitcoins. These outpoints helps nodes verify that the transaction is consuming inputs that have not been spent before. Full nodes maintain a UTXO set of all such outpoints so that they can easily verify the transaction when they get one. Since you are claiming that you have received a double spend transaction, I am assuming it means that there is another transaction that is consuming the same outpoint as the transaction from which you have got your bitcoins.

In a general case, when a chain re-org happens, transactions that were in the blocks of the previous version of the chain but not present in the current active chain are removed and moved to the mempool (provided it is valid), where it will wait until it is confirmed. But since the transaction from which you got the bitcoins is consuming the same outpoint as the transaction that is confirmed in the active chain, the double spend transaction will be discarded by the nodes as it will be invalid. Since, your spending of the double spend is pointing to a transaction that is invalid, your transaction is invalid as well.

That is the very reason it is recommended to wait for a few blocks (6 blocks ideally) before considering that you have got the bitcoins from the other person/machine. If the amount is really sizable, it would be prudent to wait for tens of block confirmations.


Isn't it safer to only encrypt the wallet, then back it up, and NOT save the seed? If you use the seed, and it gets compromised, then you immediately lost all your coins.
But if you only save the password safely, and backup the wallet file in several locations, then you gain a form of multi-factor authentication, because if the password gets compromised - the wallet file is still needed, and vice versa.

The seed may be useful for portability of the wallet, but it's a major security risk compared to just using the password and wallet file.

Am I missing something here?

Backing up the encrypted wallet file and saving the password elsewhere is basically equivalent to encrypting the seed itself and saving the encrypted seed in a different location to the encryption key. But indeed, that would require both parts to be used so would be more secure than just backing up an unencrypted seed itself


Can Ripple XRP be a good store of value with >50% ownership known? The fact that the vast majority of XRP ownership is known represents from my point of view the main threat to the value of the currency and the project itself.

Do Ripple founders and OpenCoin have any strategy in case authorities confiscate their XRP funds? Government could try to do that in order to stop Ripple development as it is done at the moment.

Would they liberate the code then so the open source community can take over its development?

If the company were to cease operations or break down in some way, the code would immediately become open source. At least one developer has that clause in their contract. If something were to happen to the company's store of XRP before the network is sufficiently distributed, at worst, the ledger would be reset. (We have contingency plans that mitigate damage, but they're not pretty.)

These are risks, and they're part of the reason that getting the network distributed and the server source code open is a high priority for us. It's not just a matter of trying to do the right thing, these are threats to OpenCoin and risk is a drag on adoption. So we want them gone as much as anyone else does.

Personally, I don't think XRP is a particularly good store of value now. It's not so much the risks you mentioned, because I think they're small. It's the unpredictability of the value of XRP due to market forces, widely variable speculation, and so on.


How to edit the label of an existing address exactly like in bitcoin-qt but instead using RPC calls? I am trying to edit the label of a bitcoin address in my wallet outside of bitcoin-qt. Currently I only know of 'setaccount' but it results in two addresses after editing one, it assigns a new address to the old label for some reason?

Does anyone know if there is a way to accomplish my goal?

accounts are groups of addresses and the label you see is the name of an account. you may list this with rpc listaddressgroupings. a key that you "relabel" with setaccount will be "moved" to the account with the new label but all other addresses stay with the other account. of course you may move all addresses to another account. basically an address can only belong to one account at a time, not vice versa.

also see How do you delete an account in Bitcoin Core?


Mining statistics dashboard I am searching for a public mining statistics dashboard that lets you see per BTC address/transaction how much was mined, when, and a way of making sure that those Bitcoins indeed come from a miner. It is necessary for tax purposes.

Any block explorer should do, if the address contains coinbase inputs (not to be confused with the company) then there's your proof of mined coins.
Read more about what coinbase transactions are here:
https://en.bitcoin.it/wiki/Coinbase
https://developer.bitcoin.org/devguide/block_chain.html


Will a channel be automatically closed if there's a expiring HTLC that doesn't have its own output in the commitment transaction? When routed Lightning payments are smaller than some amount they don't get their own HTLC output in the commitment transaction. Instead the funds reserved to it are directed to transaction fees.

When there's an actual HTLC it makes sense for the sender to close the channel and claim it back when it's expired, but it makes no sense to do the same when there's not a real HTLC in there. The same applies to the receiver.

But still, will a channel close in these circumstances?

If it's a mutual close, the HTLC will be resolved prior to closing of the channel. If the close is unilateral, then yes the HTLC which is below the dust_limit_satoshi cannot be resolved. When you are adding HTLC below the dust_limit_satoshi there is some trust element involved and hence we deduct the HTLC amount from our "balance" as a fee in the commitment transaction.

The bigger question at play is asking yourself why you are closing the channel unilaterally. There may be a number of reasons like peer is unresponsive, peer has fallen behind, or worse peer is trying to cheat. In such cases, protecting your balance in the channel is much more important than a couple of satoshis that might have been added below the dust limit.

Moreover, the fees that you will pay for unilateral close will also be higher than a mutual close. If the commitment transaction had a bunch of HTLCs, the fees from the transaction size will be much higher than the couple of satoshis that you might have added in form of HTLC that you have forwarded. So, when you broadcast the commitment transaction for the unilateral close containing HTLCs below dust limit, you will lose that much amount if you have forwarded the HTLC. Your peer will lose the HTLC amount (below dust) if it was the one that had forwarded the HTLC.


Maximum # of hashes for finding a block? Since nonce is a 32 bit number, the maximum value of nonce can only be 4,294,967,296. So, if a miner doesn't find the target hash within this number, what happens?

The miner can change the block header hash several different ways:

Change the timestamp. This is the least intrusive, but works just fine. If you can do more than 4 Th/s, this starts to become a problem.
Add transactions. Adding any new transaction changes the Merkle root, so this gives you entirely new nonce spaces.
Change the coinbase transaction. This is the most common method. 32 bits are typically used to act as an additional nonce.


Is there a way to not pay the transaction fees when using the standard Bitcoin client? I tried sending one satoshi (0.00000001 BTC) to one of my friend and the client always showed a dialog prompting me to pay 0.0005 BTC in fee, with the only options being OK (pay the fee) or cancel (cancel the transaction). The transaction was using one input and possiby two output (with how the clients jungle with the addresses).

I checked the option and the fee was at 0.00000000 BTC, but the client would not let me placed the transaction.

Yes, however the answer is a bit more advanced than for your everyday consumer:

It is recommended to have some knowledge of JSON if using this method

WORD OF WARNING: Using this method can cause large amounts of inputs being set as miners fees. I suggest you continue with caution and start by using small inputs.

That being said...

A transaction must be compiled and submitted via the bitcoin-qt console using the commands listunspent, createrawtransaction, signrawtransaction and submitrawtransaction.

To access the Bitcoin-qt console:

launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab

Use listunspent to get an array of you spendable inputs in your wallet
This is where you set you transaction fee: Use createrawtransaction to generate a transaction in the form createrawtransaction [{\"txid\":\"[txid of the input transaction]\",\"vout\":[vout that relates to the txid of the input transaction]},...] {\"[address to send your bitcoins to]\":[amount of bitcoins to send to this address],...} If you want a no fee transaction you must make sure all inputs equal the output. All inputs that are not spent in a transaction are used as miners fees.
Use signrawtransaction [the output of createrawtransaction] to sign your generated transaction Note: Your wallet must be unlocked to perform this command. If not type walletpassphrase [your passphrase] 21600
Use submitrawtransaction [the output of signrawtransaction] to send your signed transaction to the network to be included into a block

You can see your transaction by going to http://blockchain.info/tx/[txid output from submitrawtrasaction]


What is the maximum of receive addresses the default wallet can handle? I guess there is no limit. But on tests, what is the maximum before the bitcoind start to slow down in a specific machine?

A while ago I created an extension for BitcoinLib in order to put bitcoind to the test. The setup was trivial: call getnewaddress() in the main network for ever

My performance index was the number of addresses generated per second.

It took off on an average of 35 addresses/sec. I left it running on a VM for a whole month. The rounded results were:

Total empty receiving addresses    Generated addresses/sec
 < 650,000                         35
 < 960,000                         32
 < 1,240,000                       29
 ...........                       ..
 <  75,000,000                     28

The most noticeable slowdown was from 700,000 to 1,300,000.

Restarting the test client from the 75,000,000 point didn't improve the newly generated addresses per second rate. Restarting the host didn't make any difference either.

I then sent 3 payments to that wallet and they showed up instantly.

I don't know how it would affect the wallet if there were transactions linked to each of the 75 million receiving addresses but it would be really interesting to see. One thing also to be tested is whether or not there are delays during the daemon initialization when the wallet contains such a big number of addresses.

If someone has a really fast spare machine I could share the testing code and we could get to the 100 million benchmark much faster than in a month. Freewil's testnet box could be useful for that test.

Also, some related questions:

Does the original Bitcoin client scale to contain millions of addresses?

How to handle a ridiculous amount of receiving addresses?


Anomalous 2.7 BTC transaction fee observed I noticed a 2417 byte transaction with a 2.7 BTC transaction fee. Is there any rational explanation for this, or was it perhaps a mistake?

What's also possible is that someone mistakenly swapped the sending amount and the transaction fee amount. I almost did that with the bockchain.info wallet but luckily noticed it in the confirmation screen.

In this case, he could have intended a fee of 0.02314796 BTC and tried to send 2.7 BTC to the address. The other 65+ BTC could be just change.


How to setup nameserver for dns seeder? I am confused setting up nameserver to run with dnsseeder. I modified dnsseeder to work with my new altcoin.

Here is what is did.

I have vps.example.com setup with amazon ec2 and i compiled dnsseeder. I go to godaddy dns settings of my domain example.com and added my 1.2.3.4 (elastic public ip)

Hostname in Godaddy

vps.example.com  mapped to 1.2.3.4

and the nameservers in godaddy domain are like this

Type    Name    Value   TTL Actions
A   @   1.2.3.4              1 Hour
NS  @   ns27.domaincontrol.com  1 Hour
NS  @   ns28.domaincontrol.com  1 Hour
NS  dnsseed vps.example.com 1 Hour

Then i run dnsseeder

./dnsseed -h dnsseed.example.com -n vps.example.com -m root.example.com

Supporting whitelisted filters: 0x1,0x5,0x9,0xd
Loading dnsseed.dat...done
Starting 4 DNS threads for dnsseed.citizenshipcoin.org on vps.citizenshipcoin.org (port 53).......done
Starting seeder...done
Starting 96 crawler threads...done
                                                                                [18-03-07 00:49:14] 0/1                                                                                [18-03-07 00:49:15] 0/1 available (1 tried in 2s                                                          [18-03-07 00:49:16] 0/1 available (1 tried in 3s, 0 new, 0 active), 0 ba                                  [18-03-07 00:49:17] 0/1 available (1 tried in 4s, 0 new, 0 active), 0 banned; 0 DNS requests, 0

when i query nslook, it is not returning any dns ips.

$ dig -t NS dnsseed.example.com

; <<>> DiG 9.7.3 <<>> -t NS dnsseed.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44679
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dnsseed.example.com.   IN  NS

;; Query time: 1554 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Mar  7 01:40:44 2018
;; MSG SIZE  rcvd: 45

It seems something is wrong. I am supposed to receive multiple set of IPs as answer.

What did i do wrong?

Thanks for your helpJ

It's important to realize that a domain name can represent either a host machine OR a sub-domain. Name-serving a sub-domain is done by delegating the job to name servers for that sub-domain. This is done by specifying name servers for sub-domain in the parent domain's zone file.

I'm not familiar with how to delegate sub-domains at GoDaddy, but I bet your issues are at least partly in this detail.

Also, you're not showing whether your seeder is in fact finding good nodes to give when it gets a request. (In this example, we see 21/223 available)

#./dnsseeder -h myseeder.mycoin.com  -n 184.254.106.32 -m admin@mycoin.com

Supporting whitelisted filters: 0x1,0x5,0x9,0xd
Loading dnsseed.dat...done
Starting 4 DNS threads for myseeder.mycoin.com on 184.254.106.32 (port 53).......done
Starting seeder...done
[18-03-10 18:09:09] 21/223 available (223 tried in 277s, 0 new, 0 active), 119 banned; 0 DNS requests, 0 db queries

In general, the important points are to choose a host which will run the DNS Seeder software, and then delegate name service for a coin's sub-domain to it. For examples:

 Machine                                       Sub-Domain
 --------------------------------------------------------------------
 m1.platform.com      hosts name service for:  myseeder.mycoin.com
 explorer.bitmark.io  hosts name service for:  biji.bitmark.one
 jp.bitmark.io        hosts name service for:  shido.bitmark.one

In this example, we are looking at a fragment of the zone file for the domain "bitmark.one".
 We are delegating name service for the "biji.bitmark.one" sub-domain to the name server at 'explorer.bitmark.io' and delegating name service for the "shido.bitmark.one" sub-domain to the name server at 'jp.bitmark.io'.

;; Thanks to: http://www.zytrax.com/books/dns/ch9/delegate.html
;;   for info clarifying the concept of DNS delegation !
$ORIGIN bitmark.one.
www             IN      A       204.68.122.6

biji            IN      NS      explorer.bitmark.io.
shido           IN      NS      jp.bitmark.io.

If we use dig to find which are the name server(s) for shido.bitmark.one (query type NS) we get the IP of its name server, 139.162.122.138 :

# dig -t NS shido.bitmark.one

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t NS shido.bitmark.one
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21880
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;shido.bitmark.one.             IN      NS

;; ANSWER SECTION:
shido.bitmark.one.      21577   IN      NS      139.162.122.138.

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 10 09:00:44 PST 2018
;; MSG SIZE  rcvd: 75

and just to confirm who will answer for shido.bitmark.one, we see that the ip 139.162.122.138 is jp.bitmark.io

# ping jp.bitmark.io
PING jp.bitmark.io (139.162.122.138) 56(84) bytes of data.
64 bytes from jp.bitmark.io (139.162.122.138): icmp_seq=1 ttl=52 time=101 ms
...

When we query shido.bitmark.one, which is running the DNS Seeder software, for addresses (query type A),  we get:

# dig -t A shido.bitmark.one

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A shido.bitmark.one
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17729
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;shido.bitmark.one.             IN      A

;; ANSWER SECTION:
shido.bitmark.one.      59      IN      A       178.238.224.213
shido.bitmark.one.      59      IN      A       80.211.182.224
shido.bitmark.one.      59      IN      A       76.85.169.188
shido.bitmark.one.      59      IN      A       139.162.122.138
shido.bitmark.one.      59      IN      A       145.239.29.193
shido.bitmark.one.      59      IN      A       46.105.62.121
shido.bitmark.one.      59      IN      A       139.162.128.92
shido.bitmark.one.      59      IN      A       173.255.252.140
shido.bitmark.one.      59      IN      A       108.61.86.198
shido.bitmark.one.      59      IN      A       80.241.214.77

;; Query time: 159 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 10 09:09:12 PST 2018
;; MSG SIZE  rcvd: 222

Which is what we want:  a list of active coin nodes in our coin's P2P network.

It's good to remember when setting up DNS Seeding that propagation of entries in the DNS system can take time - sometimes a matter of several hours or even days.  So when testing and probing, you may want to substitute actual IP addresses for DNS names wherever its possible without affecting the testing, to avoid uneccessary DNS lookups that could provide false results because DNS entries have not yet propagated throughout.


What are the key differences between regtest and the proposed signet? What are the key differences between regtest and the proposed signet?

One of the key differences is that using regtest is not ideal for public networks as anyone anywhere can just rewrite the blockchain at their whim by mining a ton of blocks. Are there any others?

Is signet a strictly superior replacement to regtest?

If not, when would someone use regtest as opposed to signet in future?

The main difference between signet and regtest is that signet is an actual network, as opposed to a sandboxed environment.
In regtest, the network topology is entirely manual. You spin up nodes, and manually establish connections between them. You have exact control over what blocks are mined and when. This is great for testing things like consensus logic, but it's inconvenient and artificial to use it for testing actual large-scale network effects.
In signet, there is an actual network, with public nodes, operating in a way that's similar to the mainnet network. It doesn't just let you test consensus logic, but also peer discovery, transaction and block propagation, how transactions get selected, ...
Signet doesn't replace regtest; regtest was designed for use in Bitcoin Core automated integration tests and it will continue to be used there. But for other larger-scale tests, of Core and other software, signet(s) may turn out to be a better choice.


How can I code a Bitcoin JSON-RPC "getwork" request in Java? I'm not entirely sure whether to ask this question on Bitcoin-SE or Stack Overflow, but I decided to post it here due to the direct relevancy of the question to Bitcoin and the general prominence of programming experience I have observed on Bitcoin-SE. If Bitcoin-SE is the incorrect place to post it, I apologize in advance; I'm new to SE and this was my best guess.

I'm attempting, in order to better understand how Bitcoin mining works, to code a simple Bitcoin CPU miner in Java, which I have some but not much experience with. All the online resources on JSON-RPC implementation in Java I have found have either been out of date and no longer functional or incomprehensible for someone with limited Java experience. How, in the most simplistic way possible, would I code a JSON-RPC getwork request (to a pool server) in Java and correctly parse the output into the variables required for mining?

The JSON-RPC protocol is very simple.  You POST to the mining pool (or the bitcoind client):

{"method": "getwork", "params": [], "id": "anything"}

and get back:

{"result": {"data": "hex bytes....", "target": "hex bytes...", ...}, ... }

You just need the first 80 bytes from result.data - you change the last 4 bytes (nonce) and compute the hashes.  Then, when you find a hash that is less than "target" (generally a hash with the high order 32 bits equal to zero), you call getwork again to report your hash (and earn a share in the pool):

{"method": "getwork", "params": ["hex-header"], "id": "anything"}

There a bunch on wonky byte-order encoding in the standard getwork call.  You'll generally want to reverse the bytes is each long integer (4 bytes) before hashing it, and do the same before reporting your found block back to the pool.  See the sample pyminer for a simple reference implementation of a miner (in python). Inside the Miner.work() function is where the magic happens. The work function takes two parameters: datastr, this is the value stored inside result.data and targetstr this is the value stored inside result.target.

One other thing - most pools require that you use Basic Authentication when you POST, so you'll need to include your username and password in the header of your request.