|
So one thing that people have pointed out in other threads that also mention this proposal is that a someone can spam transactions which fill blocks and forces the block limit up. Miners can also lower the block limit to an infinitely small amount. I think you should also add in upper and lower bounds on what the block size limit can be. Perhaps 1 MB and 32 MB to prevent this kind of thing from happening.
|
|
|
|
|
Open an issue on github and post your stuff about armory in the proper sub forum which is Development and Technical Discussion > Alternative Clients > Armory.
|
|
|
|
|
You can always set the data directory manually by yourself.
|
|
|
|
BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.
Blah blah blah Translated: Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ... When did Bitcoin cede consensus changes to miners? Remember those other nodes, exchanges, merchants? They aren't going to be overridden so easily. Bitcoin has always had the consensus changes done by the miners. Technically, nodes, exchanges and merchants have no direct control over the consensus. It has always been and will always be the miners who make the consensus changes because the consensus changes are in the blocks, which are made by miners. Exchanges, merchants, and users have indirect control by giving miners incentives to mine for one consensus change versus another because if miners end up on a fork that no one else uses, they lose money. |
|
|
|
With BIP 101, spammers can continue to spam blocks and know for certain that for a few years they can both start another debate and the cost of continuous spam does not change that much. With BIP 1xx, the cost of spamming full blocks will double every two weeks, thus making it incredibly expensive to maintain a prolonged spam attack on Bitcoin. With the same amount of money, a spam attack would last a shorter amount of time if BIP 1xx was implemented than with BIP 101. It sounds like you have the idea of spamming blocks backwards. Spammers can't block legitimate transactions - the best they can hope is to delay no-fee transactions. A block isn't filled with the first transactions that a miner sees - the miner decides which transactions to include, based on the transaction size/priority/fee. Those spam transactions can delay low fee transactions for a long time. This is not what the block size cap is there to combat. The anti-spam limit of 1MB is there to prevent a spammer from filling the hard drives of every node operator. This is why we're not discussing moving to unlimited block size.
With BIP 101, there is no more incentive for spammers to attack than there is right now - and there has never been a spam attack in the history of Bitcoin.
Where were you a month ago when someone was spamming transactions? Don't give me BS about a "stress test" it was most definitely a spam attack. It caused 80000 unconfirmed txs, many of them legitimate. With BIP 1xx, there is absolutely something that a motivated spammer could do - they could directly control the cap, moving it higher and higher. As I said previously though, that's not really what I worry about. I worry about the reverse. Miners can truncate blocks, and directly control how much other miners can include in their blocks. It allows crippling of the open-market transaction processing that we now have. Why abdicate this to the miners - a group that has previously advocated for smaller blocks with the stated rationale that it may force higher transaction fees? It is the fox guarding the henhouse.
And no, miners can't do this right now. Yes, they can control their own blocks, but all it takes is any one miner to allow those other transactions in with small/no fee. This is a check against the monopoly that could result from BIP 1xx.
BIP 1xx is union rules for miners. Those rogue miners who will process all your low-fee transactions? They could be branded scabs, and the union masters could shrink the block size so far that the transaction fees are forced higher regardless of the remaining miners.
While that is possible, you need to see it the way that miners see it and do some cost-benefit analysis. Preventing transactions could cause several negative outcomes for miners. They would be losing out on transaction fees if a fee market doesn't develop. If the blocksize goes too low or fees go too high, people might just stop using Bitcoin causing the price to drop and thus miners are losing money. An increased backlog of transactions can negatively impact the full node by filling its mempool to the point that the node just crashes. The only positive that could come out of causing small blocksizes would be the possibility of a fee market, which compared to the risks, is not something they would attempt with their already small profit margins Also, if you think that miners would do this, then why are so many of them voting for 8 MB blocks? A solution to this problem you present would be to create a lower bound on the blocksize limit. It would be that the maximum blocksize cannot go any lower than say 1 MB (or any other number you like). |
|
|
|
3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.
...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..
Try going to store/SPVBlockStore.java and changing the constant DEFAULT_NUM_HEADERS to a lower number. I think that might help. |
|
|
|
Let me suggest something, the queue has been increased to much, what do you think to clear it? I am at 37 in queue. It's too much time to wait, isn't it?
Sometimes there is a problem with the queue where it doesn't clear out old requests. The only way I can fix it is to reboot the server program. I am fixing this in the next version with the use of an actual database instead of lists. Let me know if your position doesn't change for a few hours. That will indicate to me that I need to reboot it. I dont know how to say in the project development language, but can you do like this: Users that are not active which means that their tab is closed to be not considered and be removed from the list(queue). Do you understand me? I do understand and that is what it is currently supposed to do. Whether it actually does or doesn't is a different story. It worked in my tests so it should work in production, but may not always be the case. Have you think/test to implement the token like the other site which i found here for potential activity. That should be a good idea. So i can check now and after an hour or later on that day i can check the results with that token. So i would make that token to be valid for only x-hours. I am currently working on that as well as an email system so it will also email you (if you want to be emailed) with your results. Other changes I am adding are a database that I can go in separately to change instead of using a static lists which may not be reliable. |
|
|
|
Let me suggest something, the queue has been increased to much, what do you think to clear it? I am at 37 in queue. It's too much time to wait, isn't it?
Sometimes there is a problem with the queue where it doesn't clear out old requests. The only way I can fix it is to reboot the server program. I am fixing this in the next version with the use of an actual database instead of lists. Let me know if your position doesn't change for a few hours. That will indicate to me that I need to reboot it. I dont know how to say in the project development language, but can you do like this: Users that are not active which means that their tab is closed to be not considered and be removed from the list(queue). Do you understand me? I do understand and that is what it is currently supposed to do. Whether it actually does or doesn't is a different story. It worked in my tests so it should work in production, but may not always be the case. |
|
|
|
Let me suggest something, the queue has been increased to much, what do you think to clear it? I am at 37 in queue. It's too much time to wait, isn't it?
Sometimes there is a problem with the queue where it doesn't clear out old requests. The only way I can fix it is to reboot the server program. I am fixing this in the next version with the use of an actual database instead of lists. Let me know if your position doesn't change for a few hours. That will indicate to me that I need to reboot it. |
|
|
|
To keep the Max cap increasing, attacker needs to keep burning his coins. And once he burns out, the cap will automatically scale down. In reality, an attacker, who is willing to burn his coin can always play with bitcoin network. Recent spam experiments prove that beyond doubt. On the other hand, BIP 101 only monotnously increase the max cap, without accounting for the market demand. It does not adjust the max cap with decreasing demand for space in blocks. The exact same cost is incurred if ANY spammer wants to fill blocks. Anyone willing to accept that as a safety net should have zero problem with the exponential growth in BIP 101, since that increase in maximum block size will have zero effect on the actual block size unless they're filled. If they're being filled by commerce, great! If they're being filled by spammers, then at least there is a hard cap with BIP 101. BIP 1xx does not have the safety of that hard cap. With BIP 101, spammers can continue to spam blocks and know for certain that for a few years they can both start another debate and the cost of continuous spam does not change that much. With BIP 1xx, the cost of spamming full blocks will double every two weeks, thus making it incredibly expensive to maintain a prolonged spam attack on Bitcoin. With the same amount of money, a spam attack would last a shorter amount of time if BIP 1xx was implemented than with BIP 101. BIP 1xx as written also has the reverse problem. A few miners can collude to restrict transaction volume in their blocks, causing a repeated halving of block size CAP. A rational minority miner who would otherwise be willing to include all those transactions will find his block size restricting repeatedly.
I realize that these two scenarios are mutually exclusive - they can't both happen simultaneously. Further, I would agree that neither of them is particularly likely. The problem I have is that I don't see a rational reason to accept these possibilities. BIP-101 does not allow for either of these (unlikely, but terrible) outcomes. It follows a predictive curve, just like block rewards.
BIP 101 allows for a spammer to continuously fill blocks for a prolonged period of time, and thus sparking another debate like this on about how the block size limit is too small. It can cause a scenario like what we have now. |
|
|
|
Why does the installation of some cores such as bitcoin on linux require many different libraries and programs to be installed, other than window that (with bitcoin core) doesn't need any additional extensions at all!
The windows files comes with all of those libraries packaged into the exe file. Linux doesn't do that. As for why, I think it has something to do with the compilers. |
|
|
|
|
Get a VPN. There are a lot of different software to do this. I recommend hola and zenmate. They are browser extensions that can change your ip quickly.
|
|
|
|
|
You can attempt to do a CPFP transaction if there was an output that went to your wallet. Or you can shutdown electrum and wait for the transaction to be "forgotten" by the network in which case you can send it again but with a higher fee.
|
|
|
|
My problem isn't setting up a fullnode. My problem is how can I contact my local bitcoin core with my remote full node (bitcoind) to get rid of my local blockchain.
I dont want to use a lightweight wallet and I dont want to store whole blockchain on my local machine.
I'm not sure if this is possible.
You could set up the data directory on that server as a network share and then set the data directory of your local bitcoin core to be that shared folder. It might run into some problems and I would advise against doing this. Otherwise, there is no way to connect Bitcoin Core to your server without having to download the entire blockchain. |
|
|
|
Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.
So nodes will accept blocks with timestamp > current time ? There is a wide bounds for acceptability, I can't remember the exact bounding they use. I think the bounds are 120 minutes either way of the node's time. |
|
|
|
silliness,
letting miners agree to a block limit of 1MB - 32MB is not "giving miners too much power"
what are they going to do with this power besides make sure block limit is always about twice as much as avg block size?
So let the miners collude to lower the block size and artificially raise the fees for their own profit? I am mistaken or the incentives are VERY badly aligned? Or the people who are making the transactions stop using Bitcoin and now the miners are not making any money, or are making less. There is a disincentive and higher risk for them to be creating small blocks since it does not guarantee that a fee market would form and that people would continue to use Bitcoin if the fees started to go up. The only way they would guarantee a profit from fees would be to keep the block sizes large enough to contain a lot of transactions to collect the most fees. |
|
|
|
There would probably be an alert sent out by the developers and then they would decide whether to roll back the blockchain back to the fork point, or choose one chain and set checkpoints into the software to make sure that is the one used.
In this situation it would be hard to avoid using the longest chain, especially if it was a significant difference. Including a checkpoint in the software would be like declaring war on the majority hashrate, and they may well respond by locking out the minority until they'd got the money they thought they were owed... This isn't entirely academic, because the majority hashrate is in an authoritarian regime that's long been propped up by a good economy, and that economy isn't looking good. If they felt at serious risk of a revolution it's not hard to imagine them turning off access to the outside world. I think the upshot would be that you couldn't safely use bitcoin until the situation sorted itself out. Well the scenario he was describing and I was explaining was if somehow the network was a 50/50 split. Half of the hashrate worked on one fork the other half on another fork and somehow the blockchain was the exact same length. This is incredibly unlikely (odds are next to nothing) but if it somehow were to happen, it would completely screw with people. |
|
|
|
|
So how exactly can miners manipulate the block size for their short term gain?
One scenario that I can think of are increasing the blocksize limit so that all transactions are accepted and confirmed and then they can collect all of the fees for higher profits.
Another is decreasing the blocksize limit and hope that a fee market exists so they can earn more from fees.
|
|
|
|
Ok so I tried out Purse.io The website has an explanatory video and stuff, and there's probably a thread here somewhere about it, but my question is: how does it really work? Like: how can they get 25% or more off Amazon products from trading Amazon products for bitcoin? People are willing to pay a premium to buy Bitcoin. And who are the people that do the purchasing when you put in an order? How many of them could there really be?
They are people who have enough money to buy what you want for you and are willing to pay your price for Bitcoin. There are many people there, I have spent some time there both as a bitcoin buyer and seller. Or why would they want to purchase Amazon items for other people in exchange for bitcoin? What incentive do they have?
It is a fast and easy way to get Bitcoin with a credit card without a lot of verification. It is also a place for carders who steal credit cards and use purse.io to launder exchange the money to Bitcoin. Or how can I know I won't be scammed by someone on there?
Your Bitcoin is held in escrow by purse.io. If the item doesn't arrive, you can dispute. Since Amazon does a lot of tracking and record keeping and since it is your account that you bought the item with, it can be difficult to scam people there. |
|
|
|
It's just an interactive version, but it still doesn't explain how you can ignore the checksum without first decoding the entire base58 string. On a few tests with random keys, using the technique shown in the 2nd link I posted, the checksum characters on average affect the last 6 characters of the wif, but I did find a key that affected the last 9 characters. You can't ignore the checksum without first decoding it. By converting it to base58 from base256 the last digits will be different and with each key it varies so it is not possible to know the checksum without decoding the base58 |
|
|
|
|
Show Posts
