|
should be possible to make bitcoins algo work for such short intervals.
Main thing, don't accept blocks that far into the future, current clients are accepting blocks up to 2h in the future. *bad* idea if your retarget interval is 4 minutes.
|
|
|
|
|
Wow, I stop it for a bit and diff shoots back up to > 120 like instantly...
|
|
|
|
Yes, it's supposed to. But by adjusting the timstamp of the first and last block in each diff period you can make it retarget /4 *every single time*  |
|
|
|
|
Yes, my miners are producing blocks with "creatively adjusted" timestamps.
Using the rules I posted.
|
|
|
|
|
3Gh, and I'm not orphaning other miners blocks on purpose.
|
|
|
|
// Update nTime
if ((pindexPrev->nHeight+2) % 16 == 0)
pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime() + 1800);
else if ((pindexPrev->nHeight+1) % 16 == 0)
pblock->nTime = pindexPrev->GetMedianTimePast()+1;
else
pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
*walks away whistling* |
|
|
|
Nah, 1st one is probably someone discovering the "joy" of a hard 4kB tx size limit (*way* more convenient than those EVIL variable tx fees, eh?) 2nd seems to be for some reason stuck downloading the chain and keeps DCing his peers thanks to the "disconnect peer if he sends us more than 9 orphan tx" "improvement". |
|
|
|
|
*shrug* I still don't see how LGPL is more restrictive than SleepyCat, but... guess we'll have to disagree on that.
|
|
|
|
|
Just tested, cgminer happily mining at 1% CPU on a win7 box on dual 6970s, cat 11.6 (driver only) + sdk 2.4
|
|
|
|
|
I just don't see the massive problem here. SleepyCat (in my book a way "stronger" copyleft license than LGPL) is ok because you can rewrite the database interface, but simply removing the GUI or forking the old wx GUI is ... what? impossible?
|
|
|
|
|
While 2 pipelines could theoretically fit on a S6-LX150, routing is impossible (S6s have a lot less "long" routing resources than virtexes).
What *is* possible is one pipeline with 2 register stages per sha256 round, use SRL16s for W where possible, don't go overboard with em and don't let synthesis infer more shift regs.
And don't expect to get > 170MHz or so post-p&r on -2 without giving the placer some help.
*edit, SRL16, nor LSR16
*edit2: the xilinx docs aren't very clear on this, but a LUT6 in a SLICEM can be used as *2* equal-length SRL16s => a 32-bit wide shift reg up to 17 deep (slice FFs give the last stage) is only 4 SLICEMs.
|
|
|
|
I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.
Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns? It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL But the license of the bitcoin and bitcoin-qt code is still MIT, even though it links against an LGPL library. IANAL, but I believe this means that if you use the source to build a headless version (which doesn't link against Qt) there is no restriction on the distribution of the resulting binary. We're statically linking BDB4.7 already. Read that license? edit: to save some hunting, here it is: /*
* Copyright (c) 1990,2008 Oracle. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software. The source code
* must either be included in the distribution or be available for no
* more than the cost of distribution plus a nominal fee, and must be
* freely redistributable under reasonable conditions. For an
* executable file, complete source code means the source code for all
* modules it contains. It does not include source code for modules or
* files that typically accompany the major components of the operating
* system on which the executable file runs.
*
* THIS SOFTWARE IS PROVIDED BY ORACLE ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
* NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL ORACLE BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
* OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
* IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
|
|
|
|
|
I guess we're agreeing then. IMO the current bitcoin economy is not anywhere near the size and the future way too uncertain to have anyone blow the money required on the NRE of designing a real ASIC at a competitive structure size. But who knows.
|
|
|
|
Nope. Probability of a attacker with a given % of network hashrate (below 50%) to successfully find N blocks in a row before the rest of the network does is independent of average time/block. See the original paper. Now, here's the fun part: What about the probability of our attacker succeeding at least once in fixed timespan? |
|
|
|
|
If you could read, I wrote sASIC, aka structured asic, pretty much the same thing as xilinx easypath but without the niceness of 1:1 FPGA-to-ASIC on a HDL level.
|
|
|
|
|
You forgot a few:
I never provided any proof I had a opencl miner capable of ~150Mh/s on a 5770 back in july 2010.
I never provided any proof I had a CAL IL miner doing ~650Mh/s on a stock 5970 about 3 months later.
I never provided any proof of starting development of a sASIC miner around the same time.
I never provided any proof of getting actual devices in early march, which while providing excellent hash/J sucked at attainable clock(= hashrate) relative to cost.
And you'll probably also never see any proof I've managed to get a good deal > 200Mh/s from a S6-LX150.
|
|
|
|
|
A *bad* version of the attack could have looked like this:
Create one 1-input 10000-output transaction splitting 100.01 SC into 10000 * 0.01 SC + 0.01 fee (one output is ~35B, so only about 350kB or so). Submit it to other nodes and wait for it to get included into the chain.
While offline, create 10000 1-input 10000-output transactions, each spending one of those 0.01 and splitting it into 10000*0.00 + 0.01 fee (yes, that would have been a valid transaction!), collect all of them with a half-a-node or similar.
Inject those 10000 transactions (~350kB each) into the network at multiple points from machines with decent pipes (again, not too hard to do using half-a-node as a base).
Sit back and watch the show as nodes on the network try to cache and propagate 3.5GB of transactions.
|
|
|
|
|
I dont know of any recent fix making the blockchain growing uncontrollably.
The only issue I am currently aware of is that under certain circumstances the disabling of orphan block storage can possibly cause nodes to never catch up to the current head of the chain and under similar circumstances can also cause them to spam 1000s of "GetBlocks" requests while downloading the chain.
|
|
|
|
|
Show Posts
