Bitcoin Forum
November 20, 2018, 09:09:34 AM *
News: Latest Bitcoin Core release: 0.17.0 [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 ... 547 »
501  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15 multiwallet limit on: February 10, 2018, 05:43:21 PM
@achow101 Thanks, How are wallets actually loaded into memory? if the wallet.dat file is ~1.5M will the entire file be loaded into process memory (will that take ~1.5M in memory)?
All of the wallet data is read off disk and loaded into memory at start. So if your wallet is ~1.5 MB, then it should consume ~1.5 MB of memory.

Also, do you know if the new 0.16.0 allow creating new wallets on the fly?
It won't.
502  Bitcoin / Development & Technical Discussion / Re: Using the same block files for multiple coins on: February 10, 2018, 05:40:09 PM
Is there anyway to use the same blocks or block files for other every coin that has a QT wallet?
There is a way using symbolic links, but I wouldn't recommend it as it will likely just corrupt your block files. So in practice, there isn't. All you an do is copy and paste the data directory. When you do that, you have to make sure that the data directory you copy does not have blocks that would be invalid to the forked coin, i.e. there are no blocks after the forking point.
503  Bitcoin / Bitcoin Technical Support / MOVED: Smart arbitration contact will realize transaction between the legal tender and on: February 10, 2018, 05:34:20 PM
This topic has been moved to Trashcan.

504  Bitcoin / Development & Technical Discussion / Re: Atomic Multi-Path? on: February 09, 2018, 03:58:53 PM
I would like to disagree with you but I found in the past that the "Ban" button comes in to play so best not to say anything
that might upset the moderator.
Feel free to disagree. I'm fine with having a discussion. But its not okay when the discussion turns from actually talking about a topic constructively to trolling, mudslinging, and flaming.
505  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15 multiwallet limit on: February 09, 2018, 03:54:59 PM
There's technically no limit, but of course you do have memory limits, so at some point you will run out of memory if you load too many wallets.
506  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core does not connect to the network on: February 09, 2018, 03:54:11 PM
Please post the full debug.log file.
507  Bitcoin / Development & Technical Discussion / Re: Latest bitcoin core? on: February 09, 2018, 02:02:11 AM
The biggest differences are related to syncing performance, which is going to be significantly worse for you with address indexing enabled. There were also some database changes but that's not really a problem for you.
508  Bitcoin / Development & Technical Discussion / Re: Newbie clightning on Mainnet questions on: February 08, 2018, 04:55:09 PM
So, if I manually establish connections to other nodes, a properly working configuration should remember those prior-connected nodes, and reconnect on restart ?

Even if the connects are unfunded ?
It should.
509  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1: RPC call to re-read config file? on: February 08, 2018, 04:21:42 PM
I know. but unfortunately I was looking for an immediate solution, since the new wallet features are not yet implemented.
No such immediate solution exists.

Finally, do you by chance know of any other full node server alternatives other than Bitcoin Core that supports full node and multi-wallets with RPC? (I was hoping for a similar full node like ethereum geth where I can create separate independent (encrypted)  accounts/wallets)
You can try btcd. I don't know if they support the functionality that you want, but it is a full node.

Was this idea abandoned back in 2012 and now re-implemented (maybe?)
Most of the functions in that PR are being reimplemented or have been reimplemented.
510  Bitcoin / Development & Technical Discussion / Re: Estimating Segwit transaction fees on: February 08, 2018, 04:17:02 PM
I think it would be best, if wallets like Electrum calculate 2 fees by default. One for sending the money as fast as possible and another to send the money within 24 hours.

Not all people needs to send their money right away, so the option is needed. And if more people use this option transaction fees would fall. If the average transaction fee lowers, fees for fast transactions will also fall as a result.
Fee estimators do that. Most of them (including Electrum and Bitcoin Core) have some option to let you select different speeds.
511  Alternate cryptocurrencies / Altcoin Discussion / Re: How to clone newest Bitcoin/Litecoin source? on: February 08, 2018, 04:14:22 PM
Those files were split into validation.{cpp, h} and net_processing.{cpp, h}.

For lines that you have to change, many of them still exist just in different places. So you can use grep to search for them.
512  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.
513  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.
514  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.
515  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:
516  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:
517  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 ?
518  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.
519  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.
520  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.
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 ... 547 »
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!