Bitcoin Forum
February 19, 2019, 11:49:04 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 ... 551 »
601  Bitcoin / Development & Technical Discussion / Re: Newbie clightning on Mainnet questions on: February 08, 2018, 04:12:16 PM
How do I see a list of already generated addresses,
There should be a command for (I don't remember what it is). You can list commands using the help command.

where is this data stored ?

Also, what happens when I fund a channel, and lightningd crashes ? Are the funds gone ? Does it remember I had the channel open and funded ?

Finally, when I manually connect to servers using the cli, is there any way to have it remember them when I relaunch lightningd ? Sorta plays into the hesitation of losing funds if it crashes; is it not supposed to remember prior connections ?
It has its own data directory where there is a database file. All of that information is stored in the database and will be loaded next time you start so that everything persists between restarts.
602  Bitcoin / Development & Technical Discussion / Re: How are unique address in Bitcoin calculated? on: February 08, 2018, 06:39:45 AM
Addresses cannot be deleted; in fact on a technical level, there are no addresses.

What that chart shows is how many unique addresses contains coins. Recently many people have been moving their coins to segwit wallets which means that they are consolidating their coins into fewer addresses. Furthermore, many people have been doing such consolidations to avoid paying higher fees in the future.
603  Bitcoin / Development & Technical Discussion / Re: Estimating Segwit transaction fees on: February 08, 2018, 06:37:44 AM
It's that Core's fee estimation (like Electrum) is bad.
Compared to other fee estimators, it's very good. Note that Electrum basically uses Core's fee estimation (the estimation from the Electrum servers which use Core as the backend).

Which leads me back to square one: How are people estimating their fees with Segwit? There's gotta be a better way.
Many people look at fee information charts like and choose a fee rate based on what outbids most transactions. Unfortunately this kind of pattern seeing and the processes that the human brain does in order to make such a decision is hard to do algorithmically. Note that just doing that in software is actually very gameable and ignores a ton of other information that helps make a better fee rate prediction.
604  Bitcoin / Development & Technical Discussion / Re: MultiSig: Is there such a thing as 'reverse SSS' ? (Shamir secret) on: February 08, 2018, 03:26:43 AM
What you are interested in is key and signature aggregation. Recently such a scheme using Schnorr signatures was announced. The thread about it is here:
605  Bitcoin / Development & Technical Discussion / Re: bitcoin wiki: target calculation mistake? on: February 08, 2018, 01:01:13 AM
0xFFFF0000 is a compact representation of the target. The target is a 256 bit integer, but is compacted into a 32 bit form that can be stored in blocks. What that format is is described here:
606  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 08, 2018, 12:58:07 AM
1. Transaction ids received from GBT should be reversed byte-wise or used as is to calculate markel ?
Things are only reversed for display to the user. On the protocol level, things are used as provided.

2. Considering the is no transaction so sha256d of coinbase becomes the markel and 2xhash output of coinbase should be used as is in block header or it should flipped byte-wise ?
ex: 2xSha256 of below coinbase
The sha256d of the coinbase will be the merkle root if there are no other transactions.

01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2c03dc851300043c487b5a0c5a7b47ff0100000000000000066e5175616e740d2f6e5175616e 742e706f6f6c2fffffffff026fe2ab04000000001976a9144ab4b2aa35879fe47e6a16ea783494f 9dcf615b788ac0000000000000000266a24aa21a9ed60af3e8651f28353ad47a0664c3892b67d82 0d3828af0c5dc854fc2e0bec44d200000000

= 5cb15257b783b9a4c12d1425ad80985a9d43ee474019d5026d04a0e80090f32b

So block header should use it as is or it should be flipped ?

As is. This is correct.

3. Submitblock param = block header + (number of transactions + 1 for coinbase) + coinbase + All the transaction data field received from GBT . Is this correct ?
607  Bitcoin / Development & Technical Discussion / Re: Estimating Segwit transaction fees on: February 08, 2018, 12:54:40 AM
I also haven't wrapped my head around satoshis/bytes vs. satoshis/vbytes and how to figure out how much transaction size is allocated to witness data.
vbytes are calculated by first dividing just the size of the witness data by 4 and then adding that to the size of the non-witness data.

I basically just eyeballed the Core next-block fee in satoshi/byte and reduced it by 25% to be on the safe side.
Bitcoin Core's estimator actually uses vbytes, it's just labeled improperly.
608  Bitcoin / Development & Technical Discussion / Re: Atomic Multi-Path? on: February 07, 2018, 07:14:29 PM
So how excited should I be while it still appears to be in the concept phase?  Is it one of those "if it sounds too good to be true... etc" deals?
You should be fairly excited. The proposal comes from Laolu, one of the primary architects of the Lightning Network and main developer of LND. While perhaps the proposal as it was exactly written in the email won't happen, I'm sure that something very similar to it will be created and implemented.

Has anyone identified any pitfalls or shortcomings yet?  Or is it simply too early to tell?
There is active discussion about this on the mailing list (I haven't really been following), and it is still in the concept phase so expect the proposal to change and the issues worked out over time.
609  Bitcoin / Development & Technical Discussion / Re: any way of deriving legacy private key from a segwit address for forked coins? on: February 07, 2018, 07:08:27 PM
Segwit addresses are not derived from legacy addresses. However a legacy address can be derived from a private key for a segwit address, and vice versa. Private keys are just numbers and are not locked to a specific type of address that they should be used to create.

Note that Electrum uses a special format for private keys in order to indicate what type of address they should be used for. You will need to export those private keys and convert them into a format that your forked coin's wallet can understand.
610  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1 re-d/l ? on: February 07, 2018, 07:05:11 PM
which can be found here,
That is the old website. The correct one is

do you know what armorydb.exe is? big thanks for replies...  Grin
Armorydb.exe is the backend for the Bitcoin Armory wallet. It communicates with Bitcoin Core and builds its own databases and block index from Bitcoin Core's data. This is what actually performs the transaction scanning stuff.

ArmoryQt.exe is the GUI application for Armory. It relies on ArmoryDB in order to function.
611  Bitcoin / Development & Technical Discussion / Re: Why did satoshi develop bitcoin in windows? on: February 07, 2018, 04:45:33 PM
He probably only had experience programming in windows and with GUIs. Bitcoin 0.1.0 was a Windows only, GUI only application.
612  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1 re-d/l ? on: February 07, 2018, 04:31:45 PM
The 'bitcoind' app is 'bitcoin daemon'? What exactly does that do?

It does everything that Bitcoin Core's GUI does but without a GUI. it's meant for people running headless servers or who just don't like GUIs.

And- do I need to open bitcoin core every time before opening Armory? Thanks for your reply-
613  Bitcoin / Development & Technical Discussion / Re: Understanding transactions (testnet) on: February 07, 2018, 04:29:50 PM
I've looked through the scripting part and tried to understand it as good as possible, but it still doesn't make quite sense to me why you'd do something like this?

Can you come up with a usecase?
It's testnet, people experiment with random things on testnet. It's possible that the transaction was a mistake and a bug in some software produced it. But it happened on testnet and that's fine.

It's also possible that someone is experimenting and learning how scripts work, so they created that transaction. It's testnet and that's okay, that's what testnet is for.

It really does not matter why such a script exists; you just need to know that it does and such scripts can exist so you need to be able to handle them.
614  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 07, 2018, 04:26:04 PM
Thanks, Below is the request received from pool, so if you check first header above which looks like big endian has previous hash as is.
It is not big endian.

I do not think that this is exactly what your miner received from the pool. I think what you are seeing is based on an internal representation of the data which makes it appear to be different than what it actually is.

So bloc header has previous hash flipped in 32 bit chunk ?
That is what is being displayed, but that is not what it actually has to be in the block header.

But as per documentation it doesn't say so.
Because your miner is displaying that information incorrectly.

prev_hash: da780ff935f3917ed99a7b616cb98ebb3104b3fa000b7acd0000000000000000
The correct block hash is f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000. You will notice that if you byteswap this so that it is actually in big endian, the block hash becomes 0000000000000000000b7acd3104b3fa6cb98ebbd99a7b6135f3917eda780ff9 which is an actual block that you look up on a block explorer or node. Looking up what your miner is displaying in both its original form and byteswapped form results in not being able to find such a block.
615  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core & Milestones on: February 07, 2018, 04:15:52 PM
The new issues and PRs are related to critical-sh bugs found in RC1 and RC2. The final version will be released when those bugs are resolved and no new ones are found with the next RC.
616  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1: RPC call to re-read config file? on: February 07, 2018, 04:14:32 PM
New rpc command "reloadconfig" to dynamically update configuration parameters (Issue #309). Command line parameters will not be overridden. Notice that many core parameters are used only during startup.

But such command does not seem to exists.
Because that Pull Request was not merged.

Why do I need it? - it seems that adding an entry wallet=mynewwallet.dat will create a new mynewwallet.dat if it does not exists when the program starts.
This is good since I want to be able to dynamically add wallets in a multi-wallet mode. but the server needs to restart entirely which is bad for me.

Is there an option I missed in Bitcoin Core RPC to reload the conf file? My version is 0.15.1 on Windows 10.
No, there is not.

Reloading the bitcoin.conf file comes with a lot of potential consequences that can result in strange or broken behavior. There are many things that have to happen at startup in order for some things to work.

What you want is unrelated to the bitcoin.conf file. There is no need to let the bitcoin.conf file be reloaded in order to allow for wallets to by dynamically loaded and unloaded. Instead of jumping to that extreme, we can just add a feature that lets you dynamically load and unload wallets. In fact, there is an open pull request for exactly that: It is not merged yet so this behavior does not currently exist in Bitcoin Core. But hopefully in the next major release, it will.
617  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 07, 2018, 05:33:17 AM
cgminer log shows stratum header constructed as below
20000000da780ff935f3917ed99a7b616cb98ebb3104b3fa000b7acd0000000000000000854e4bd db4eeb7c1841b651ceb26f4d12116bfcc2c41ed18220fd701571914ba5a6fdbfa176c2146000000 00

Look at version, time, difficulty part. Shouldn't it be flipped as big endian ?
No, everything in Bitcoin is serialized as little endian. Actually, this is serialized as big endian, but in kind of a strange way. It seems like it is being printed out with each 4 byte chunk (32 bit integer length) in big endian, which also means that the merkle root and previous block hash fields are messed up. But this is not the actual block header it is hashing.

And at the calculation of midsate its flipping all 4 bytes.. meaning 00000020f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000dd4b4e8 5c1b7eeb41c651b84d1f426ebccbf162118ed412c01d70f22
This is the correct block header. Everything is in little endian as it should be. This is what the block header should look like.

When submitblock is called, what should be sent as block header ?
The second one.
618  Bitcoin / Development & Technical Discussion / Re: Bitcoin's earliest developers on: February 06, 2018, 04:47:03 PM
Sipa is the only person still working on Bitcoin on that list, and is therefore the longest serving programmer in Bitcoin development. So Sipa has probably contributed to Bitcoin development more than anyone else.
I'm pretty sure that sipa was only added to that list so that he could help migrate/maintain the bitcoin-dev mailing list. Development had moved from sourceforge to github in 2010 before the sourceforge repo was abandoned.

IIRC all of Wladimir, Pieter, Greg, Gavin, Jeff, and Matt all got involved within months of each other in 2010-2011. I think Wladimir is actually the longest contributing active contributor.

The person who contributed the longest and is still somewhat active is actually Dooglus.

A good place to find this kind of history is to scroll through the git log in reverse (i.e. earliest commit first).
619  Bitcoin / Development & Technical Discussion / Re: Bitcoind - Getbalance command on: February 06, 2018, 04:02:00 PM
You can't do it with bitcoind/Bitcoin Core. In order to find the balance of an address, an address index is required. But maintaining an address index is expensive and not that useful since the node does not need it to operate, so one is not maintained. There is no code in Bitcoin Core to build such an address index.

It is important to note that addresses and balances do not exist on a technical level. It requires significant computation to produce balances for all addresses, and requires a lot of additional storage space to store that data.
620  Bitcoin / Development & Technical Discussion / Re: Why the fuck did Satoshi implement the 1 MB blocksize limit? on: February 06, 2018, 05:40:02 AM
This thread has devolved into a lot of trolling, mudslinging, and flaming. Thus it shall be locked.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 ... 551 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!