So then, a reliable metric for node operation is to keep track of the information being broadcast to the network. Since it's the capabilities of the network that we care about, maybe there would be a simple integer appended to the information broadcast to the network indicating if the node is below or near it's peak capabilities? If every node attached this information to the messages it transmits to the network, and then it was read as an aggregate from the completed blocks, it would only add 2 bytes to the minimum size for a block and then the block as a whole could be read to determine the average. The information transmitted is also an aggregate of various factors applied to the machine, to give an average which ends up being more of a vote.
So, as an example: Suppose we have 10 nodes participating in a specific block. 6 of them report a 0 - indicating that they are well below capacity. 3 reports a 1 to indicate that are near capacity. 1 reports a 2 indicating it is at it's limit. That means we have 6 votes to increase the cap, and 4 votes against, but only IF the current block size equals the current block size limit. If they are full, the next block has a slightly higher ceiling. The amount of which could be based on an additional digit within that integer as some signal to the network of how much more it can handle. The consequence is that the node which is at capacity won't be able to participate in as many transactions, so will get fewer votes.
That is a simplified example since a given node might have thousands of transactions that it has participated in, but that's OK. If it handles more transactions it has more votes, meaning that smaller nodes that are not as capable might participate in less transactions given it's self identified capability rating. Giving node operators who have a wallet attached to the node a piece of the transaction fee for participating in this process would provide incentive to a node operator to upscale to handle more transactions.
Now, if the reverse happens where a majority of node operators vote that they are at capacity, the network might cap there, or if the votes are leaning towards it being too much the network might scale back - even if the block isn't full. A formula could decide how much to scale it back as well.
I don't see any reason why we can't do this.
Any metric that requires self reporting and cannot be independently verified to be true is easily gameable. Suppose I really want larger blocks. What prevents me from spinning up a few thousand fake nodes (you can't tell they are fake, they all look real as that is just the nature of nodes) and then having each node vote saying that it is super overloaded and we need Gigabyte sized blocks now? What prevents me from lying? What if I am actually experiencing no load at all but I claim to everyone else that I am absolutely overloaded? There is no way for you to verify that what I am saying is true or now without having direct access into my machine. Are you really going to trust what I say and take it at face value?
That doesn't mean there's a limit to how long the channel can remain open though, so in cases of people who leave it open indefinitely that ends up being even worse for everyone else who uses on chain transactions compared to those who occasionally close the channel.
Why would it be worse for everyone else? They aren't making transactions on chain, so no one else is effected.
In general, changing what the block size limit is requires considering more than just transaction fees and capacity. You also have to consider things like the potential for increased orphan rates, the potential for fee sniping, whether nodes can support the larger block size, any potential attack surfaces or ways that different block sizes can exacerbate current issues (e.g. quadratic sighashing), etc.
Lastly, a meta note. Please don't make so many consecutive posts to respond to each post individually. Do them all in one post. You can separate each response using a horizontal rule as I have done here. |
|
|
|
Guys, anyone tried using this on a Mac?
Of course! There's a mac build and Bitcoin Core is routinely tested on Macs (some of the developers use Macs). |
|
|
|
|
This is not the place to ask for people to tip you for using a free accelerator service or to ask about accelerating transactions. Use a thread if you have a problem with that. All posts asking for help and offering the same accelerator service will be deleted.
|
|
|
|
This topic has been moved to Trashcan. Insubstantial |
|
|
|
This topic has been moved to Trashcan. Insubstantial |
|
|
|
This topic has been moved to Trashcan. Illegal activity is not allowed on this forum. |
|
|
|
Maybe theymos has intentionally blacklisted such bots to put a hold on account trading?
People are farming accounts and this forum is turning into a spammers hub.
I won't be surprised if this turns out to be true.
Certainly not, more due to the easing website functioning, we are constantly dealing with difficulties accessing website for a large number of browsing people. I don't think a single crawler was putting any load on the servers.I think the website used to analyse accounts by stacking the queries, one by one(correct me if I am wrong). So, it won't make any difference to the performance if it is blocked or not. Probably, account farming is the main reason for this. Theymos switched to Cloudflare and that's blocking basically all bots at this point in time. That's why the site is down now. |
|
|
|
This topic has been moved to Trashcan. Trashcanned upon request |
|
|
|
Now i couldn't understand it at all  When I going to Bitfinex or Bittrex I am able to generate my own address to Transfer Tethers..So, this is not database only.. Those are different services. It is database only for the same service. So Tether.To wallet to Tether.To wallet is database only. But Tether.To to Bitfinex or Bitfinex to Bittrex is not a internal service transaction, so there are fees there. |
|
|
|
I know the fee is too low. But Chain.so shows the transaction, does this mean that this transaction is in Chain.so's mempool?
Yes. Also, do all nodes have a mempool? or just miners?
Most full nodes have a mempool. However you can also configure one to not have one and operate in blocks only mode. If the fee is too low that other nodes won't accept this transaction, only Chain.so has it in the mempool, does it mean that I have to wait until Chain.so successfully mines a block?
Chain.so is not a miner. If your transaction is not in anyone else's mempool (and determining this is impossible to do), then your transaction will not be mined. You can remedy that by rebroadcasting the transaction to the network so that it does enter all nodes' mempools, but it may drop out of them again later, so you would have to rebroadcast again later. |
|
|
|
Thanks for the reply. But where are the input signatures "stored" and hashed, and how does that "free" space from the blocks to allow more transactions to fit in? The more I try to learn the more questions I have.  The signatures are stored as part of the transaction. Because legacy nodes will not see the signatures, there is effectively more free space in the block for more data that those legacy nodes can see (e.g. more transactions). What actually happened is that the block size limit was redefined to something called block weight. There is now a block weight limit, which is 4000000 weight units. Each byte of non-witness data (everything that a legacy node will see) is worth 4 weight units. Each byte of segwit data (everything that a legacy node won't see) is worth 1 weight unit. So if you use segwit, more bytes of your transaction will be in witness data than a comparable non-segwit transaction. So the weight of your transaction is lower and thus there will be more weight for other transactions in the block. That is where the capacity increase comes from. |
|
|
|
If you want Bitcoin ABC to use a different data directory, start it with the -datadir=<path> option where <path> is the path to the place you want its data directory to be. |
|
|
|
Any idea what the rationale is for not allowing a different path to your wallet.dat ?
The wallet.dat file is a database. When the database is opened, other temporary files will also be opened in a given location. That location is usually the Bitcoin Core datadir. However having the temporary database files and the wallet database itself located in two different places may cause issues, especially with unclean shutdowns and moving wallet files. Thus to avoid issues with that, wallets must be in the same directory as the temporary database files, which is the datadir. This is also why symlinks have also been disallowed. That they were allowed in the past was a bug. |
|
|
|
I can send coins to all of those addresses, and to 3rd party observer that will look like balances on different unrelated addresses.
If I'm correct, are there any flaws or security risks in this?
Not necessarily. P2PKH (legacy) and P2WPKH (bech32) addresses contain the same data, the hash160 of your public key. So anyone scanning the blockchain will immediately know that if a P2PKH output and a P2WPKH output have the same hash160, then the owner is the same person. Regarding security risks, there are none. And if I'm importing private key to some kind of wallet software, how wallet determines which address to scan on blockchain and which balance to consider as wallet's balance?
It doesn't know. Currently, if you import a WIF format private key (as is the current standard), most wallets will interpret it as the private key for a P2PKH address. Some wallets may have settings that let you tell it to make a P2WPKH or P2SH-P2WPKH address, but there is no standard for that. It is currently up to the implementations. However the creator of the bech32 standard is currently working on a similar encoding for private keys. This encoding would specify the type of witness output that a private key is for so wallets can use that to determine what address to create and scan for. |
|
|
|
|
The change address is part of the wallet itself. So you already have the private keys for all addresses (the ones you give out and the change addresses) and Armory will manage them for you. You do not need to worry about them yourself.
|
|
|
|
Thanks for the reply. Ive been trying for days to fix this. I still have no idea what to do. I am totally surprised how little there is in terms of dev support.
If you want help from the developers, this forum is not the right place. The place for that would be either the github issues page or the Bitcoin stackexchange (more Bitcoin Core developers are active there than here). I am reformatting my storage drive and removed bitcoin core entirely. I am going to try to reinstall once more
Reinstalling will do nothing to help. The issue is not with your installation but more likely with the data in the datadir itself. That data is not removed or touched by any installation process, so reinstalling will not do anything to that. I suggest that you first backup your wallet then wipe everything in the datadir except the wallet file and let Bitcoin Core redownload the full blockchain. The total lack of help is kind of stunning...
Your problem is extremely specific about an issue that few or no people have seen before. The only people who might be able to help you are the developers (of which I am one of) and even then some may not know because this issue pertains to a part of the codebase that few people actually have worked on. |
|
|
|
I am sorry, but this is a totally useless answer, as far as I am concerned.
First, is the answer to my question yes or no ?
I guess you didn't read the thread that was linked, because it should be clear from my answer that the answer to that question is Yes. Then, can someone name a wallet that support BCH and BTG ?
AFAIK, there is no trustworthy wallet that supports both BCH and BTG simultaneously. Finally, can someone name the different steps to be followed ?
The steps are right here: |
|
|
|
When are they generated, when I decide one to be generated? Or before I get the device?
How can I confirm that? can I review the source code on ledger, bitbox (not trezor) etc?
To be honest, if people seriously buy a piece of hardware with a preloaded pk and uses that..... oh my. For me that would be like security 101, NOT TO.
Even if I decide to trust the manufacture/company... which I dont. How could i know the ratailer didn't duplicate that key, how could I know that the post mail main who delivered the device didn't unpack my package and duplicated the key? How could I know that some intern in the production factory didn't duplicate the keys etc.
The keys are generated when you initialize the device. The devices come uninitialized. You can also reinitialize an already initialized device. This will wipe the existing private keys from the device and have it generate new ones. 2. Is it possible to "swipe" the hardware wallet and load your own private keys? And if so, is this easily done?
It depends. If your private keys are part of a BIP 32 HD wallet and you have a BIP 39 mnemonic for that wallet, then yes. You can load the BIP 39 mnemonic onto the device and it will generate the proper keys. If you just have a bunch of private keys that were randomly generated (or you don't have the BIP 39 mnemonic), then no, you cannot. 3. If I can put the hardware wallet in my laptop and send crypto currency stored on it to other address, what would keep a malicious piece of software on my computer from changing the address as I confirm the transaction?
You have to confirm on your device before it signs the transaction. If the outputs are changed after signing, the transaction will be invalid. If they are changed before signing, then you will see the changed address on your device and can tell it to not sign the transaction. 4. Is it possible to; from a totally offline computer holding the private keys. Make an transaction, move the transaction to a usb key, plug that key in a online machine, publish the transaction to the blockchain, so that the private keys never "touches" a machine with internet access.
Yes. I feel that the info text and video explanations on trezor and legder, bitbox is just showing some little usb thing and showing that "when you plug it out your money is safe" but they never explain the technical background that makes that possible. There is no explanation on why your private keys was not duplicated the moment you plugged it in to your computer, or before you even got the device. And there is no noob safe guide to load your own pks to the hardware wallet.
It is impossible to duplicate the private keys when the device is plugged in as they keys cannot leave the hardware (well they could if you have malicious firmware installed). The firmware for all of the devices are open source and publicly viewable and auditable. If you don't trust the firmware that came with the device, you can install your own self-compiled version. The only firmware that is not open source is the firmware for Ledger's Secure Enclave. The Secure Enclave is where the private keys are stored. However things to and from the Secure Enclave must pass through the rest of the Ledger's open source firmware sop you would be able to see whether the Secure Enclave is leaking your private keys. |
|
|
|
|
Show Posts
