47 BTC -> 50 BTC
50 BTC -> 47 BTC
Another possibility is just having change. 47 BTC -> 47 BTC
50 BTC -> 47 BTC
-> 3 BTC
Then the 3 BTC is considered still unmixed by the original owner. This avoids DOS attacking the txout set, and requires fewer fees. Another useful optimization is to trigger these activities when you want to make a payment so that it's not even creating an extra transaction and the ownership of the outputs is further clouded (e.g. in that example there could be 1-2 senders and 1-3 recipients who may or may not be the same as the senders). |
|
|
|
I came up with a idea for myself, and then CableZ asked how
I realized other people could benefit by it, but I said
I did not know if addnode was needed
that I get about 85 connections average(65-100 variable) at any given time per ip, not 1000 --- I put 1000 in to see what happens <-- nothing happened so you could put 100
Benefits
1. Faster Blockchain download from a new client
2. Observation - fast solo mining pauses with 8 connections when the block changes, due to new block being loaded - you lose about 4% of your hash power -observing shares submitted to backup non-solo mining pool.
If you have a high connection count the block is loading faster, I am observing a .005 % loss to block loading now.
(#2 is real observation, people could somehow argue whatever)
Your observations are flawed though I can't tell how with how little information you provided. In Bitcoin the block is always sent sequentially with one peer at a time. They do not increase your download speeds. And if you do reach 1000 connections you will crash. |
|
|
|
maxconnections=1000
This is asking for memory corruption and or FD exhaustion that will cause it to crash and potentially corrupt your wallet. Good luck with that. |
|
|
|
With Asics early adopter - better off mining solo, so you need a really well connected node
Having large numbers of connections is counterprouctive because block relaying is serial, you're more likely to get stuck feeding to some slow edge host in Africa for 30 seconds the more peers you have. what use is finding the block if you lose the race to claim it?
It is quite rare that two solutions are found within seconds of each other. The formula is p=1-e^(-1/600*delay_seconds) so there will only be a contest within 10 seconds 1.6% of the time, and even if you're slow to propagate you still may win it. After all, your competition experiences delays too. It's bad to be slow, but being fast isn't terribly important. Having a fast node— e.g. SSD or tmpfs storage for the blockchain, ultraprune, fast machine with lots of ram— is more important than connectivity... but it's still not terribly important. |
|
|
|
LTC works and is solid. Can a faster coin work? You seem to think no, however I bet we will try and see.
I'm not saying it will work 9a BTC clone) but it will be tested. Waiting 2 hours for 1 confirm is not going to work... If it fails we will have to start from scratch. I'm not here to support BTC, I'm here to revolutionize the way value is transferred around the world... Deal with it. Don't worry, I'm sure the facts won't get in the way of whatever ponzi scheme you're planning on participating in next or people adopting the NextGreatThing designed by people who haven't a clue about what they're doing or the patience to learn. The facts didn't stop people from trading Liquidcoin for BTC for a little while... until the facts caught up with them and made it vanish. I console myself with the fact that all the suckers and scammers are so slow to learn from their own mistakes that they just keep repeating them and its easier for the sane bystanders to avoid. |
|
|
|
Yeah, like once every 4 years... But anyway a faster coin will come around soon enough...
Not one based on the bitcoin algorithm. Litecoin is already too fast most likely. The Bitcoin algorithm is not convergent when the highest latency (including all block validation time) bisection of the hash rate becomes higher than the mean time between blocks. E.g. if a chain has a 3 minute average block time an it takes 3 minutes for some half of the miners to hear from and validate another half, then most of the time a new block will be found in each half before it's heard about the other half's blocks and the two will form longer and longer forks, which take longer and longer to reorg between. The result is a partition with the halves not able to agree on the history of transactions. At current transactions levels (which are only a portion of the maximum allowed) Bitcoin is already seeing multi-minute propagation in some cases. Litecoin's blocks could well be far enough apart to escape being doomed from this— escaping with just needing to wait for some more confirmations to cope with larger reorgs due to slower convergence (as the number of confirms you must wait for a given confidence goes up as you approach the latency bound); but it seems unlikely that the bitcoin algorithm could go much faster successfully. It's a shame people don't even bother to learn from all the failed altcoins who have twiddled Bitcoin's parameters without understanding them or their reason for existence. They weren't set the way they were just to piss you off.  |
|
|
|
This is why LTC
Except LTC can also take 90 minutes for a block too, it will just happen less often. I didn't know. Will 0.00050001 BTC (standard + 1 satoshi) give me an advantage in priority?
Maybe. The current reference software sorts transactions by fee per KB data size. Due to rounding that tiny increase may make no difference depending on your transaction size. Paying less that the base fee won't help at all, very tiny fees are just treated the same as free transactions. Historically even the base fee would have given you a substantial advantage. But the dice site is flooding the network with 0.0005 BTC fee transactions so free and 0.0005 transactions frequently get to wait. |
|
|
|
This does not work because the BFL's have not enough memory (RAM) onboard.
And you need that for LTC mining.
No, LTC mining intentionally used parameters _far_ smaller than the scrypt recommendations— You only need ~128k. I'm sure that there is enough distributed sram on those FPGAs for that, although there may be routing constraints or not enough room for them and the hashing engines. The reason the GPU scrypt miners use a lot of memory is that they must run many instances in parallel to get high performance (to hide the memory latency and to use all execution units). A typical FPGA Bitcoin miner runs just one instance unrolled. |
|
|
|
Than why not simply add what you typed, or condensed version, to pop-up which triggers once stated condition(s) occur? I mean,
8+ hours installation is highly unusual this days. There's plenty of time for user to conclude something is not right and just deinstall
client, than turn to some other solution, in worst case those trustless online wallets.
Because the software doesn't know it isn't done, otherwise it would continue. It happens now when the peer you were pulling from goes aware or becomes unresponsive. One of the things about making a secure zero trust client is that you just can't count on 'servers' to tell you what you need to know, there is a lot of complicated interlocking behavior which can have unexpected outcomes. Improving this aspect of the IDB processis planned, but software isn't written through wishes. If you'd like to contribute please test and write procedures for testing and report bugs, or chip in on fixing some of these things. Posting ideas here is only of modest assistance (most of the time such recommendations are already known but aren't handled yet because no one has had a chance, or because they're tricky). |
|
|
|
it happens many times that client just stops downloading data and seemingly goes
to idle mode. Mentioned situation happens even if many other nodes are connected. I've found somewhere that it can be a sign of DDoS.
Whoever was telling you this was mistaken. This is an expected behavior during the initial block download currently. It will begin pulling again when there is a new block on the network. |
|
|
|
As soon as it hits 2016 blocks, it resets it back to make 10 minutes a block.
Well… not quite. It's only linear for sane changes— though it does have quartic convergence even in crazy cases. |
|
|
|
exa*
No no, it's an external device... so it does exohashing, of course. |
|
|
|
|
Hi, this thread is created in response to the thread requesting 65 GH from the SC single.
Everyone knows that more is better, and since >9000 exahash is more than 65 GH (perhaps infinitely more) then it is clearly the best option.
I think BFL should begin making these alterations to accommodate these speed increases with all haste.
|
|
|
|
We need a breathalyzer function on the forum to govern posting access.  Can you please keep this garbage out of the technical forum? |
|
|
|
Going down at the same time as pirate doesn't prove he was using pirate. He could have been using zeekrewards directly. |
|
|
|
In Quartus using my "prototype" code that I used for Hardcopy IV evaluation,
and other Stratix and Cyclone V devices (I would remember that for Cyclone V
it is possible to get 320 Mh/s performance per chip @ 160 Mhz @ 6 W approx).
The same code on EP3SL150F780C4 gave highest clock 220 Mhz, and on
EP3SL150F780C3 gave highest clock 250 Mhz. It is exactly unrolled round calculation.
And clock is based on "Slow 110mV 85C Model Fmax Summary" so if some overvolt
practice done it would run a bit (probably like 10%) faster.
I suspect you're bumping into the same reason their initial specs didn't match the delivered product: the power (and perhaps clock?) estimates out of these tools are wildly wrong because they don't account for the very high toggle rates. Your numbers would have been more in line with what BFL originally claimed for the product but couldn't deliver. |
|
|
|
Nobody produces ASICs to achieve several times better performance than FPGAs, there are other advantages.
Gibberish. |
|
|
|
Ok, so I don't have anything created or compiled or made, but I think it would be extremely interesting to see how a bitcoin-clone with blocks confirming every second would actually work. Sure, confirmations would get reversed all the time, then rebuilt, then reversed again, but eventually, a transaction would make its way into a generally accepted longest chain.
Depends on how you define "eventually". If there exists a partitioning of miners such that the mean time between blocks is less than the communications and block processing latency for a block to propagate completely is less than the mean time between blocks then the bitcoin algorithm will take infinite time to converge in the average case. In Bitcoin at current transaction levels we now see propagation times at several minutes sometimes. High orphan rates and lots or reorganizations also slow down convergence, so in practice you probably need to have a block time considerably greater than the latency bound or bad things start happening. But hey, if you plan on reporting the many coin-generic bugs I'm sure you'll find then it's all good, and might be a fun exercise even if it's doomed to fail. Have fun! |
|
|
|
|
Show Posts
