Pruned mode is paradoxical because you need to be able to download the entire thing at least once... which kind of defeats the purpose.
No, that is its express and only purpose. Pruned mode is for the sole purpose of reducing disk space. It has nothing to do with bandwidth and was not designed for reducing bandwidth or computation requirements. It was literally designed to only reduce disk space usage. |
|
|
|
Using bitcoin without specifying from which addresses are you going to send money was always pointless to me if you wanted any sort of control over the privacy of your money so I need to be able to choose what inputs I want to use (I use "Coin Control" for this which is one of the main reasons I used Bitcoin Core's client) but trying to do this manually adds the possibility of screwing things up.
Then use the lockunspent command to prevent Bitcoin Core from selecting certain outputs. The idea would be to do enter things in a nice and clean GUI and then save it in a txt file, too bad im not a coder so the only thing I can do is hopefully someone sees this and implements it.
This is also the billionth time you have asked for it. If you want a feature, asking for it here is not the way to go. The vast majority of Bitcoin Core contributors don't read this forum. If you have a feature request, make an issue on the github page if there is not already one. |
|
|
|
Yes it is I think I had a password on my old qt would that not show a balance unless I put it in or only if I was to try and send?
This question is nonsensical and does not make any sense. Can you rephrase and make it clearer, perhaps with some punctuation? |
|
|
|
|
Is Bitcoin Core fully synced?
|
|
|
|
|
Did you choose to set the datadir to where it was originally on the external drive? If not, it is using the default location and it won't know to look for the data on your external drive.
|
|
|
|
Yes I do have a "addnode=127.0.0.1" in my bitcoin.conf
Why? Bitcoin Core does not need to connect to itself. Addnod'ing your local node is why this is happening. You don't need to have addnode set to use Armory either. |
|
|
|
|
You probably missed a character.
|
|
|
|
I am not 100% sure... wasn't there this OP_CHECKMULTISIG off-by-one error, and you had to put a hex "0" before the signature?
See the explanation in Andreas' book "Mastering Bitcoin" (2nd edition) in chapter 7, page 150 ... (book is online available)
The point of this is to not validate the redeemScript. Thus that is not a concern. |
|
|
|
You will need to change this line: https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.h#L54 and remove "SCRIPT_VERIFY_P2SH" (just change that to be 0). The way that P2SH is enforced is that, at this point, all new blocks and transactions must pass the P2SH checks. Changing the chainparams parameter for bip16Hash will only effect the verification of old blocks. |
|
|
|
Let's say Tom funds a channel between himself and his favorite coffee shop with 1 BTC to buy coffee daily, but this coffee shop is local and has few customers using Bitcoin. That 1 BTC will decrease over years, but at the same time not really accessible to anyone else. So in a way, Tom is still hoarding that coin, because it is not for sale on exchanges.
If enough people buy coins to fund these "private" channels, then it will eventually decrease the overall supply of coins in the market, right? <If these channels are not frequently used by other people>
The point of LN is that there are multiple payment channels over which payments are routed. Sure the "actual Bitcoin" (whatever that may be) itself is not moved, by the value represented by it is. So the coffee shop can, if it has a channel open with an exchange, effectively sell the Bitcoin you paid him. 1. If Tom only opens that channel between himself and the coffeeshop, presumably, the coffeeshop will want him to close the channel every week or every month, wouldn't they? Because only when the channel is closed can the final version of txs be broadcast to the blockchain, and only then can the coffeeshop "realise" the coins in their wallet. I don't see many small businesses willing to open channels with each customer - so it might not work very well in that direction (of the customer opening the channel).
The coffee shop could route payments through Tom if the channel has enough balance. He's a node on the network, thus if he has other open channels, then payments can be routed through him. |
|
|
|
I believe at this point my testnet node is accessible to other folks however my node is still 'unreachable' on https://bitnodes.earn.com/. Bitnodes only shows mainnet nodes. They don't list testnet nodes. Is my testnet node running correctly at this point?
Yes. |
|
|
|
Cmon, and for a central graph the routing is trivial, but for a random distributed?
Its not solvable and so LN is limited to central ones,
... You know that path finding algorithms have existed for decades right? You know what decades of research has gone into path finding algorithms and quickly finding fast solutions, right? Have you considered that maybe some other thing has run into a similar problem with a large, distributed graph and having to find a good route from point A to B? Maybe something like Google Maps. Or maybe how the internet routes your packets. This is not a new problem, and there are known solutions to it. At this point in time, it's really not that hard to figure out how to quickly find an optimal route in a large, distributed graph. Literally decades of computer science research has been dedicated to this topic and applied to many large distributed graphs that you probably don't even think about. not even thinking of 'funding', economical and regulative issues that are also strong fix point attractors for centralization.
In what way do you think that those will attract centralization? The very design of LN makes it so that anyone, at any time, can create their own LN node that serves as a "hub". Even if LN does become centralized around a few large hubs (which I think is unlikely given how easy it is to create your own LN node that is a "hub"), those hubs cannot be a central authority that can take away people's money or force channels open or to never close like an actual central authority can. The user is still in charge of his own money and he can always close a channel unilaterally to access his money. So when I want to route money to someone, my software has to ping all of my channels, then have their channels ping theirs etc, every single time?
No, that would be horribly inefficient. Your LN node stores locally all of the channel information that it knows about. When a channel is updated, that node will announce to the rest of the network that that channel was updated, so all nodes will update their local knowledge of the network graph. |
|
|
|
Agreed. Yet, man, it would be a huge obstacle, at least for me personally, to open up my channels for routing. I mean, there's a reason why I'd have $2500 in the channel with my landlord and $25 in the channel with my coffeeshop and not the other way around.
I'm thinking though, I could move money around my own channels for free I guess? *EDIT* no that won't be possible, user B can't move money into channel 2 because then the channel's worth would be over 2 BTC. The only way would be an on-chain transaction, right?
You can loop money back to yourself to re-balance your channels. |
|
|
|
but having to construct the raw transaction manually is a mess for most people.
You would have to specify the change address and remember that it contains the Bitcoins etc...
The whole process has been made way easier with the fundrawtransaction command. You don't have to figure out the inputs anymore nor do you have to do anything with determining change outputs. With fundrawtransaction, you just need to use createrawtransaction and specify only outputs, no inputs. Then you pass that into funrawtransaction and it will fill in the inputs and create a change output as necessary. The resulting unsigned transaction can then be signed with signrawtransaction and broadcast. Sure the UI could use a bit of work, but it's relatively simple to use if you know how to read instructions. Core really is not designed for or setup for doing the airgapped machine setup. It is first and foremost a node software, not a wallet or GUI software. If you want a certain feature, you can either implement it yourself or find/hire someone to implement it for you. The Bitcoin Core developers are not your personal slaves to implement everything as you wish. We often have more important things to do related to the network as a whole than to implement GUI features. If Armory can have a good GUI for this I don't see why Core's client cant.
Because the are for different use cases with the developers focusing on different things. I don't like how these softwares handle the private keys, I don't find safe the idea of being able to "spawn" your entire private key collection with a single seed,
Bitcoin Core will be switching to creating HD wallets only with Bitcoin Core 0.16. Of course it is still backwards compatible, but new wallets cannot be non-HD. |
|
|
|
to get all fees , you need to get list of all trasnactins in mempool
getrawmempool will give you all transactions "txid" in mempool.
then you need to run
getrawtransaction "txid" 1
it will give you detailed transaction in json.
from that you can get
"vin"
"vout"
fees = vin - vout
do this for all transactions and you will get fees of all transactions in mempool.
hope this helps.
This would only work if OP has txindex enabled on his node. |
|
|
|
That makes a lot of sense from a logical point of view. However what does sound weird is that B didn't do any transactions himself and now is out of money on channel 2! If he wants to make a payment in channel 2 he actually needs to fund it again. So if you're not doing a payment yourself but are part of a route, then it's possible money transfers from your one payment channel to your other payment channel. Hmm...
B is likely to be chosen for a transaction that goes in the opposite direction, so over a long period of time, his balance will even itself out as C will send back to A (or be part of a route that includes C -> B -> A). This I dont follow, do you have an example maybe? I'm not sure what you're trying to say here.
In Channel 1, B's commitment transaction will look like this before the route is established: Funding input --> B's local output 1 BTC
--> A's remote output 1 BTC
After the route is established, the commitment will become Funding input --> B's local output: 1 BTC
--> A's remote output: 0 BTC
--> HTLC offered to B from A: 1 BTC
Once B has the necessary information that would allow him to spend from the HTLC offered output, he can talk to A and settle this off chain by combining that HTLC with his local output, so the commitment becomes: Funding input --> B's local output: 2 BTC
--> A's remote output: 0 BTC
|
|
|
|
How does this lightning network work and by extension other lightning networks that will come in.
To keep it decentralised, will every node runner mine every transaction in their pool.
Is there some sort of order transactions will be stored by (ordered transaction hash numbers or something)?
No. Just No. Read the lightning paper: https://lightning.network/lightning-network-paper.pdf |
|
|
|
|
Your computer has had Bitcoin Core installed on it before. There are settings and data which are not removed when you uninstall Bitcoin Core. That is what is causing your problem.
You can change the datadir by starting Bitcoin Core with the -choosedatadir option.
|
|
|
|
When can we expect a nice GUI support for this?
Probably never. |
|
|
|
|
Show Posts
