|
This does not seem like a leaked link. Anyway, wallet design looks promising. Lets wait for more updates from them especially about security.
|
|
|
|
BIP101 is finished
I'm still trying to figuer out excatly what this 8MB option is.
As I understand it, it is just an indication that a miner can add in a block that they support 8 mb increase. They can do that without any real implementation. ya but this 8MB Block would be on running Core? has the Core dev team actually proposed to implement 8MB block should the network agree? This is what we are discussing. Final decision has not made. Personally, I don't think maximum block size will be increased to 8 MB. |
|
|
|
The only reason that BIP101 is bad is that there is the possibility that it will be attempted to be implemented without consensus. There is no real reason why the network would not be able to support 8MB blocks on a technical basis and Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.
Moore's law? It looks like you aren't up to date with that one. Intel confirmed in 2015 that the pace of advancement has slowed, starting at the 22 nm node around 2012 and continuing at 14 nm. Brian Krzanich, CEO of Intel, announced that “our cadence today is closer to two and a half years than two.
It is going to get worse from here, until the transition to something entirely new. The growth factor in BIP 101 is not sustainable and people should be aware of this. That's one of the main problems. Okay then change BIP101 so that the max block size doubles every 2.5 years. Problem solved. Plus the change in timeframe is only the short term trend which is hardly an indication of what will happen between now and the next 20 years. Regardless if Bitcoin is to remain decentralized the max block size needs to increase, and it needs to increase a lot over time. Otherwise it will become too expensive to use and people will be forced to either use the traditional banking system or centralized systems like LN and side chains. There is no way around this. There is a good chance that it might get more expensive to run a full node. Doubling maximum block size every X years is not a good idea which is what BIP 101 is about though in it X is 2. Even though it is dynamic increase, maximum block size increase should depend on more/better factors. |
|
|
|
There’s been a lot of discussion in the past couple of weeks about Bitcoin, the online virtual currency whose value has been extraordinarily volatile of late. A currency that’s electronic but as untraceable as cash surely has its uses for some people, but there’s one aspect of it that hasn’t been fully considered yet: its uniqueness may not last.
National currencies have one great advantage over currencies like Bitcoin: they usually don’t face much competition. It’s true that countries with weak currencies sometimes use dollars, euros, or even cigarettes as alternative or parallel mediums of exchange. Broadly speaking, however, a national currency is a useful focal point; the government requires that everyone accept it in transactions, and so everyone can agree to use it. That’s what makes it valuable.
National currencies are considered as currency or have more value because nations considered it as its currencies. It does not make other currencies valueless. Bitcoin is not so well-defined as a currency in comparison to a dollar or yuan, and thus its uniqueness is much less clear.
I explained it above. The currency based on a mysterious algorithm
Its not at all "mysterious". whose originator is anonymous.
True. But what's the problem in that? He should be anonymous to save himself. No one really knows whether the algorithm can be trusted to generate Bitcoins as promised,
Everybody who has read the code knows it can be trusted. In fact, there is no "Bitcoins" in "Bitcoin". or who would be accountable for errors or frauds;
Such as? there is no definitive monetary authority.
That's why, it is decentralized and people are able to store their money without trusting a third party. It is not a mandatory for a currency. Were any problems to occur, a new electronic currency, perhaps one vouchsafed in a more transparent way, might arise. If the people who found Bitcoin useful for its anonymity, virtuality, and globality were to switch to this new currency, the value of Bitcoins would tumble. The reason is simple: Bitcoin’s exchange rates with other currencies depend on supply and demand; if no one wants Bitcoins, they’re worthless. And Bitcoin need not run into trouble for a new currency to appear. The new currency’s originators just need to invent an architecture that people prefer. Of course, people won’t switch away from a popular currency for the sake of small improvements. But Bitcoin is just the first virtual currency to make it big – and you can bet it won’t be the last. http://bigthink.com/econ201/bitcoins-big-problemIt is same for every currency. It is not only applicable to Bitcoin. |
|
|
|
According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."
It is still a problem. What's a problem? Storage space required to run a node? Bandwidth. what? the miners don't have bills?
we don't fully use the 1mb and out of gavin(CIA)'s ass we jump to 8mb?
wtf!!!
blocks sometimes do get filled up and we'll see more and more of that as Bitcoin grows. You want to wait till its a dire situation before expanding the bandwidth? wtf!!! Right but should we jump from 1 MB to 8 MB? bullshit!!!!!!! they never get filled! even with the spam from coinwallet.eu! i don't scratch if i dont have an itch!  Transaction backlog is there and legitimate transaction gets rejected or take longer than usual. |
|
|
|
According to Gavin, storage space won't be the bottleneck in the future , but rather bandwidth.
"The (pruned) ledger only takes up 1 gig and will be further optimized."
It is still a problem. |
|
|
|
The only reason that BIP101 is bad is that there is the possibility that it will be attempted to be implemented without consensus. There is no real reason why the network would not be able to support 8MB blocks on a technical basis and Moores law would imply that technology will advance quickly enough so that the network will continue to be able to support the increasingly large max block size and if it doesn't then then Bitcoin can be formed again.
BIP 101: Doubles maximum block size every two years.IMHO, its not a good idea. CMIIW. There wasn't a need for 1Mb limit 4 years ago either, we could have done away with 256Kb or 512Kb just fine. In fact, up until recently the hard 1Mb cap wasn't effective at all as it never was approached. But smaller soft limits were all hit and raised. That's how Bitcoin survived.
As this time we are discussing rising the hard limit (via hard fork) we need to future proof it a little bit. In this light, 8Mb seems reasonable as a new hard limit for the next 4 years, in conjunction with smaller soft limits that miners can agree to maintain internally to prevent network spamming and abuse. They can, for example, agree to not build on top of anything larger than 4Mb initially, however full nodes will still accept and propagate blocks all the way up to 8Mb. This way the infrastructure will be ready for soft expansion in the future.
Whether to expand beyond 8Mb, when and how is questionable and depends on many factors. Maybe a series of hard-forks down the road will be a more appropriate and responsible solution than trying to predict the technology, but anything less than 8Mb for the upcoming years might start hurting Bitcoin and deflect its user base towards other solutions. We, as a community, definitely don't want that.
I know, maximum block size as 8 MB does not necessarily mean all blocks after that will be 8 MB. IMHO, its better for a gradual increase than a jump. However, I might support 8 MB but I am still opposed to BIP 101. |
|
|
|
Tor exit nodes are automatically downloaded which is a bad thing and Tor exit nodes IPs have lower priority.
Not ideal, but not necessarily a bad thing. It will only occur if you are running your node in the open - in which case you are broadcasting your iP address anyway. If you are running behind a proxy, then the download doesn't occur at all, and no attempt is made to intervene in possible dDos attacks. What about preventing Tor network usage? Still not a bad thing? |
|
|
|
-snip-
The code has forked, but the blockchain hasn't. It's an open source coin and that means anyone is allowed to fork the code. Anyone can make a change to the code and release their own client. If that client sends and receives altcoins on an alternate blockchain, then yes, it's an altcoin. If, however, it sends and receives bitcoin transactions following Bitcoin's blockchain, then it's still Bitcoin. If the fork goes ahead, the longest chain remains Bitcoin and the other one will not be. Consensus is not a central group of developers reaching agreement. If you don't want people to be able to release their own clients with their own proposals for how to run the network, why are you using an open source coin? Neither Core nor it's developers are a permanent authority on what Bitcoin is or should be. If you want a coin where the developers make all the decisions and the users have no choice, you have the option of using a closed source coin.
You are right! Once a >1 MB block is created, the blockchain forks. I did not meant consensus from core developers as consensus. Consensus for >1 MB block is there but not for BIP 101. I am also for maximum block size increase but we haven't got a good solution yet! CMIIW. - Claiming XT has suddenly introduced the possibility to log or ban IPs when this has always been possible is not honest behaviour.
Unlike Bitcoin Core, it is "default" behavior of XT. Indeed, and if the other thread has simply stated that in an honest fashion, I doubt it would have gone on for so many pages and caused so much of a stir. The purpose of the thread was to cause a panic and discredit the developers. Hence dishonest behaviour. If they had simply said what you just did, I wouldn't have taken issue with it. Yes, by default, if the node is being flooded or DDoS'd, it will prioritise which connections to keep and which to drop. But this is nowhere near what the other thread was claiming. Fair enough. |
|
|
|
I have 5 prefix letters , what is the command line for find at least a BTC address for it ?
Case-sensitive prefix search:"path\to\vanitygen.exe" 1Prefix
"path\to\vanitygen.exe" -i 1Prefix
"path\to\vanitygen.exe" -k 1Prefix
"path\to\vanitygen.exe" -k -o anything 1Prefix
Edit: Searching for compressed key is faster than uncompressed key. Download Lifeboat's vanitygen. See https://bitcointalk.org/index.php?topic=301068.0. Also, see https://bitcointalk.org/index.php?topic=25804.msg10590011#msg10590011. Case-sensitive prefix search but not limited to 1 match and saves all matches to a file (compressed):"path\to\vanitygen.exe" -k -F compressed -o anything 1Prefix
What are command lines for oclvanitygen ? does oclvanitygen use graphic card for computing ? and this is faster than vanitygen ? Commands are same except you will have to select OpenCL device using -D command. If you have only one OpenCL device and you did not specify, Oclvanitygen automatically chooses the device. Else, it will give you an error. Eg:- "path\to\oclvanitygen.exe" -D 0:0 -k -o anything 1Prefix
-snip-  -snip- |
|
|
|
This code doesn't actually block anything, just marks it as being lower priority than non-Tor traffic. It should never do anything unless there's an active DoS attack via Tor. So perfect accuracy isn't really needed here: Tor access still works fine and will do even if you run a Bitcoin node and Tor node on the same machine.
That said, I'll make a mental note to switch to the second URL when I work on this code again (might be soon, given the ongoing DoS attacks via Tor we're seeing).
It explicitly says it disconnects addresses with low to negative priority. This would be the first time in history that anyone was blacklisted from using Bitcoin if XT forks, it's a big deal and against the fundamental reasons Bitcoin is used. It's blocking attackers during an attack, and even restores their connection when an attack is over. I don't see anything wrong wit this. Tor exit nodes are automatically downloaded which is a bad thing and Tor exit nodes IPs have lower priority. |
|
|
|
sidechains sound like they could be a great innovation. the issue that I see is they are being used to justify keeping the blocks small. Why should we be forced to use sidechains? Why can't we have sidechains AND bigger blocks?
But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive. The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with. Then what? Emergency doubling? That won't cause another argument at all, will it? Come on. This sounds like an all-or-nothing fallacy to me. We don't have the 'perfect' solution so its better to do nothing? I don't agree with that. I would rather see 8mb now while solutions continue to be developed. Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence. 8Mb is what Bitcoin needs in order to have twice the capacity of its closest PoW competitor. However a soft cap of 4Mb might be a good safety measure for the initial ramp up schedule. Whether doubling should occur every two or every four years and what an ultimate cap (if any) should be is all debatable. Yes. We need to have bigger block size to handle a high number of transaction but we can't just increase to 8 MB because of that. Its always better to increase block size gradually. Now, there is no need for 8 MB and doubling every X years does not make sense. We need dynamic block size, of course, but a better one. |
|
|
|
-snip-
- XT has a list of TOR exit nodes, and can read an updated list of TOR exit nodes.
- ONLY when the connection limit is reached, instead of blindly blocking new connections, XT will select a TOR exit node to disconnect to allow the new plain connection.
- When the DOS attack is over, those connections will once again be accepted.
Both automatic download of TOR exit nodes and "IP prioritizing" are bad IMHO. They do more harm than good. |
|
|
|
-snip- However, we'll see if those currently engaged in said fraudulent activity are prepared to make any compromises themselves.
Fraudulent activity? Was I not clear about that part? - Running a client to spoof your version and manipulate the figures is not honest behaviour
- Impersonating satoshi to "discredit" the fork proposal is not honest behavior
- Dismissing the fork proposal as an altcoin is not honest behaviour
This has gone away from a "proposal. It already forked without consensus but lets wait and see... -snip-
It's only an altcoin if it forks without consensus.
-snip-
- Attempting to sweep discussion on both forums and reddit under the carpet is not honest behaviour
It is an altcoin. It forked without consensus. So it does not belong under "Bitcoin" discussion unless if that talks about Bitcoin and not XT solely. The forum is not deleting XT topics but moving it to Altcoin board. - Claiming XT has suddenly introduced the possibility to log or ban IPs when this has always been possible is not honest behaviour.
Unlike Bitcoin Core, it is "default" behavior of XT. The best part is, no one can stop them from doing these things. They're perfectly entitled to do as they please. But they aren't doing their cause any favours. People aren't stupid and if they suspect something underhand is occurring, it's only going to make them dubious of the motives involved.
|
|
|
|
|
Are you planning to use this addresses? If not, use Blockchain.info and sweep all Bitcoins to your Electrum wallet.
P.S. Please move this back to Multibit. It is the right section.
|
|
|
|
why does the wallet takes trillion year to get synchronized  cant the professional developers find an alternative . Obviously, your clock is moving very fast! In normal speed(eg:- Earth's), it takes a few hours to few days if you have >130 Kbps with >512 MB RAM. |
|
|
|
...
And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments...
I support increasing the block size limit. Right now, showing support for XT seems to be the most efficient means of achieving that goal. Longer term, I would like to see several implementations of the Bitcoin protocol controlled by different groups of developers. In other words, I'd like the square on the right here to have several smaller squares inside it (and no square [including Core] > 30%), thereby decentralizing development: [ img width=800]https://i.imgur.com/VzqyqwR.gif[/img] What in your opinion would be wrong with that longer-term goal of decentralizing development? Many clients, each (hard)forking blockchain. How great would it be?!  |
|
|
|
"Leadership"? That means, to make Bitcoin centralized?  Difficulty is a measure of how difficult it is to find
a hash below a given target.
The Bitcoin network has a global block difficulty.
Valid blocks must have a hash below this target.
Mining pools also have a pool-specific share
difficulty setting a lower limit for shares.
This thread is not talking about mining difficulty. |
|
|
|
sidechains sound like they could be a great innovation. the issue that I see is they are being used to justify keeping the blocks small. Why should we be forced to use sidechains? Why can't we have sidechains AND bigger blocks?
But why support such a poor design for increasing the blocksize? The entire class of proposed solutions are presented as permanent solutions, and yet when you walk through the logic, you realise that static limits are too restrictive. The inevitable colossal fees so derided under the mythical "1 MB 4ever" position can just as easily be reached in January 2016 if the use of the network suddenly jumps higher than the 8 fold blocksize increase. Doesn't sound at all implausible to me, it's what we're trying to encourage with the change in carrying capacity to begin with. Then what? Emergency doubling? That won't cause another argument at all, will it? Come on. This sounds like an all-or-nothing fallacy to me. We don't have the 'perfect' solution so its better to do nothing? I don't agree with that. I would rather see 8mb now while solutions continue to be developed. Of course, its not better to do nothing. But is bad better than nothing? Is not it better to discuss more to find a better solution than to implement a bad one? 1 MB now is not a problem now except when blockchain is spammed by so-called "stress test". IMHO its better to wait a little than to implement BIP 101. No offence. |
|
|
|
|
Show Posts
