[0.65 BTC]

Hi,

I have 4x bottles of 120 x 150 mg ursolic acid.  Dose is 2-10 capsules per day.  Selling bottles for 0.65 BTC each shipped or less if you buy more than one.  Shipping within USA and Canada.

It's a fairly new supplement, however in mice on high fat diets it shows fairly strong effects at a dosage of 0.14% ursolic acid in foodstuff.

HFD = high fat diet, HFD + UA = high fat diet and ursolic acid

PLoS One. 2012;7(6):e39332. doi: 10.1371/journal.pone.0039332. Epub 2012 Jun 20.
Ursolic acid increases skeletal muscle and brown fat and decreases diet-induced obesity, glucose intolerance and fatty liver disease.
Kunkel SD, Elmore CJ, Bongers KS, Ebert SM, Fox DK, Dyle MC, Bullard SA, Adams CM.

It also increases muscle density and strength in the mice while decreasing white (bad) fat.

Jasinlee and LaSeek have announced their intentions to market an FPGA that does scrypt hashes.  Their claim is 400 KH/s at a wattage in the low double digits, for a standalone wifi-connected unit at $300 USD.  LaSeek claims to have worked on hardware optimizations for the scrypt algorithm for FPGA that allow for lower memory utilization while enhancing the number of logic unit cycles required.

This is all yet to be verified, but proof of concept will be presented soon according to them.

[02 / 09 / 13 @ 11:57:57pm EST]

When novacoin was posted here on the 11th, there were already 210,000+ coins mined.  Where did those go?

The details for novacoin were first posted in the russian forum on the 10th:
https://bitcointalk.org/index.php?topic=114712.0

Here is the timestamp for the genesis block: 1360105017 (02 / 05 / 13 @ 4:56:57pm EST)
Here is the timestamp for the first block: 1360426882 (02 / 09 / 13 @ 10:21:22am EST)
Block 1500: 1360475877 (02 / 09 / 13 @ 11:57:57pm EST)

Reward is as follows:

Code:

nReward = 100 / (nMaxTarget / nCurrentTarget) ^ (1/6)

At block 1500 we have some 110,000 coins mined (max block reward is 100 and decreases with difficulty; at block 1500 reward is 62.580000), and it goes down with every block.  This was all mined before February 10.  Balthazar (alexhz) uploaded the source to github on the 9th and didn't appear to announce it.  In fact, binaries didn't even appear until the 10th.

Here's a post of Balthazar showing already 500+ blocks mined before release: https://bitcointalk.org/index.php?topic=114712.msg1512980#msg1512980

Originally announced to be released Q2 2013 inline with the launch of Haswell (Intel's latest offering) both AMD and Nvidia have both decided to postpone their release until at least October.

http://www.vortez.net/news_story/amd_and_nvidia_supposedly_to_delay_the_launch_of_their_next_generation_grapics_cards.html

Looks like we'll be waiting a while for 8970s :|

https://bitcointalk.org/index.php?topic=140099.0

What do you think?

Hi,

I read the following links:
https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Dump_format#CBlock
https://en.bitcoin.it/wiki/Block_hashing_algorithm

And I'm still a little confused on how the block header is hashed.

First off, how are the transactions that are not part of the coinbase transaction attached to the block?  Why does hashMerkleRoot change if a new transaction enters the network?  I understand the these are being updated constantly, but are there two hash trees in any given block, one for normal transactions and one for the coinbase transaction?  How is the hash tree assembled for for the normal transactions?

When we hash the block header, are we hashing all 640 bits contained inside of it (which constantly change)?  I understand that the hashing goal is to produce a result containing a certain number of trailing zeroes based upon the difficulty, but I'm confused about the data we're hashing and how the addition of transactions changes it, and how the inclusion of our coinbase value and address changes it.  I know the first transaction for any given block is the coinbase transaction, but I'm confused as to how the addition of this into the block we're hashing changes this.

This might be a stupid question.  As I understand it, pools work on a PoW principle similar to that of bitcoin in that they hash the block header in an effort to produce a result with a number of trailing zeroes.  This number of trailing zeroes is far less than required to actually claim a block on the network.  This lower difficulty result is sent to the pool and the pool confirms the validity of the lower difficulty share, which results in a fractional payment.

My question is: How does the pool prevent the miner from screening the shares they generate for a large number of trailing zeroes that would afford them the whole block at the current difficulty?  If a miner could do this, they could just steal blocks from the pool.

Obviously it doesn't work this way, so what was the solution?

Hi,

I'm working on a bitcoin fork right now and I'm trying to figure out something related to data structures.

I want to develop a blockchain (hash tree) whose algorithm for hashing subsequent blocks is determined as a function of the nonce of the 0th, 0th + c, 0th + 2c, ... , etc block (leaf) where c is a constant.  I assume that the nonce values are pseudorandom and non-predictable, but I don't know if that's actually true.

Which leads to the question: Can I compose a hash tree like this?  What kind of problems do you think I'll run into, and are they impossible to overcome?  I want to see if anyone knows the answer to this before I begin trying.

I don't know if this kind of hash tree has a name or not either, or if it's been implemented before.  I guess it might be called a polymorphic hash tree.

Stratum mining allows LTC pools to achieve less than 0.5% stales.  The only current pool to implement it is ltcmine.ru.  If you check out their list of miners there, you will see that many are mining with quantities of stales as low as 0.2%.

Latest version of cgminer to support it is 2.10.2
The reaper version that supports stratum is here: https://bitcointalk.org/index.php?topic=92522.msg1372243#msg1372243

I think as a community we work on getting stratum support for more pools, so that you guys pool mining all get more litecoin.  Currently, PoolServerJ supports both litecoin mining and stratum.

Everyone's probably noticed that a bunch of people are only mining LTC every other cycle (3.5 days) to take advantage of lowered difficulties.

What effect do you guys think this has on the coin?

I think it may actually act like the blockchain reward halving, as people mining at the high difficulty are much less likely to dump their LTC into the market (and hence half the LTC is really reaching the market from people dumping at low difficulties).  Certainly it hasn't really hurt litecoin's price, which has been consistently above that of BTC.

Greatest %/day decreases in years

Ruh roh

coinotron, litecoinpool, and notroll are all down.

burnside's pool is still up, though.

My rigs are outside here.  Right now it's -24C outside and my rig's hard drive is running at 16C (my CPU amazingly is at 12C).

My question whether or not the hard drive will stop working below a certain temperature?  It's get into -40 to -50C here and it's possible that the HDD temperature will go below 0C.

Also at what temperature do brushless fans (on the video cards/CPU) generally stop working?

[Statements from BFL Josh/Inaba/BFL themselves]

Statements from BFL Josh/Inaba/BFL themselves

So will the BitForce SC product line REALLY come out in October? This is a fair question.  Let's review our track record.  If you're not aware, our initial product, the BitForce Single had a slow delivery cycle.  This was initially due to a last minute design change before initial product release.  When we did release it, we weren't quite prepared for the explosive success we had.  After several rounds of scaling, single delivery is in sufficient volume to catch up quickly. The Mini Rig product release has followed it's development and release timeline pretty well.  Initial deliveries aren't far from estimates and the speed of production is on pace to ensure most customers will get their Mini Rigs ahead of schedule. The SC product line has been under development for quite some time and is not the result of an expedited development process.  Although there are always issues during development, our team is highly experienced in exactly this field and we're currently ahead of our original timeline.  Honest Abe, we're scheduling shipments for October of 2012.

http://www.butterflylabs.com/bitforce-sc-release-notes/

So, we've got he myriad distributors shipping thousands of little pieces to us, the PCB manufacturer sending us the bare PCBs, the HSF manufacturer sending the HSFs to us, the PSU manufacturer sending the PSU's to us, the case manufacturer sending the cases to us and most importantly, the fab sending the ASIC chips to us. All of these must arrive on time and as expected for everything to go off without a hitch. So far, so good.

October 10, 2012
https://forums.butterflylabs.com/showthread.php/104-Shipping-in-2-3-weeks?p=1461&viewfull=1#post1461

We wanted to cover the bases with the Bitcoin Mag article, so we pushed the shipment date out.

With regards to an updated shipping schedule, we are waiting on some information with regards to the bulk shipment of our ASIC chips. Once we get a confirmed date on the bulk shipment, I will have a pretty solid idea of exactly when we will start shipping, but until I have a more exact date with regards to the chips, I can't give a better estimate. Once we have the chips in hand it will take a couple days to get them pushed through our pick and place house and then ready to be shipped out. Chances are, either I or someone else from BFL will be going in person to be sure each step is executed as quickly as possible and to handle any unexpected contingencies that might crop up.

At this point, though, I very seriously doubt we'll make the end of October. How far into November that is pushed I should know sometime soon (this week, I hope).

https://forums.butterflylabs.com/showthread.php/188-Information-from-Bitcoin-Magazine?p=2636&viewfull=1#post2636

I would like to know what one or two individuals (in the US preferably, unless the non-US person wants to pony up a ticket) that Bitcoin Talk community would nominate and accept as credible, verifiable individuals to be flown here to KC sometime around the end of October/Beginning of November time frame to see our facility, inspect the manufacturing equipment and test out the devices.  We don't have an exact date yet as to when we would do this, but I would like to get the ball rolling as far as names in the hat and see if there's even a vague consensus on who the individual(s) might be.

https://bitcointalk.org/index.php?topic=112543.0

See further in this post: https://bitcointalk.org/index.php?topic=112700.msg1297999#msg1297999

Come on guys... if this was ANYONE else except for BFL they would have had scammer tags already!  The community has given them hundreds of thousands of their dollars, waited month upon month, and has not seen a word of honest discourse from them about the state of their products.

If you're waiting on something, why not tell us?  Why not tell us what it is?  Why not at least provide process details for your ASIC like Avalon?  Ridiculous.

[util.h]

PPC: util.h

Code:

#include <openssl/sha.h>

template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

template<typename T1, typename T2>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
                    const T2 p2begin, const T2 p2end)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256_CTX ctx;
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
    SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
    SHA256_Final((unsigned char*)&hash1, &ctx);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

template<typename T1, typename T2, typename T3>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
                    const T2 p2begin, const T2 p2end,
                    const T3 p3begin, const T3 p3end)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256_CTX ctx;
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
    SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
    SHA256_Update(&ctx, (p3begin == p3end ? pblank : (unsigned char*)&p3begin[0]), (p3end - p3begin) * sizeof(p3begin[0]));
    SHA256_Final((unsigned char*)&hash1, &ctx);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

Bitcoin: util.h

Code:

#include <openssl/sha.h>

template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

template<typename T1, typename T2>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
                    const T2 p2begin, const T2 p2end)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256_CTX ctx;
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
    SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
    SHA256_Final((unsigned char*)&hash1, &ctx);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

template<typename T1, typename T2, typename T3>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
                    const T2 p2begin, const T2 p2end,
                    const T3 p3begin, const T3 p3end)
{
    static unsigned char pblank[1];
    uint256 hash1;
    SHA256_CTX ctx;
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
    SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
    SHA256_Update(&ctx, (p3begin == p3end ? pblank : (unsigned char*)&p3begin[0]), (p3end - p3begin) * sizeof(p3begin[0]));
    SHA256_Final((unsigned char*)&hash1, &ctx);
    uint256 hash2;
    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
    return hash2;
}

output of diff: no differences

PPC: script.cpp

Code:

    // Serialize and hash
    CDataStream ss(SER_GETHASH, 0);
    ss.reserve(10000);
    ss << txTmp << nHashType;
    return Hash(ss.begin(), ss.end());

Bitcoin: script.cpp (old version)

Code:

    // Serialize and hash
    CDataStream ss(SER_GETHASH, 0);
    ss.reserve(10000);
    ss << txTmp << nHashType;
    return Hash(ss.begin(), ss.end());

output of diff: no differences

Am I missing something here?  It sure looks merge minable to me.

Order ID: 952
Date Ordered: 02/10/2012

Your order has been updated to the following status:
Ready To Ship

To view your order click on the link below:
http://www.btcfpga.com/index.php?route=account/order/info&order_id=952

The comments for your order are:

Hello, we are excited to let you know that your order and payment has been processed. Your shipping invoice has been printed and will be ready to go when your bASIC has been assembled and released from test.

Thank you for your business!

The BTCFPGA Team

Please reply to this email if you have any questions.

So we can infer:
1. Final ASICs have been cut out from the wafer and will be tested.
2. PCBs will be assembled soon after.

It looks like December will be the month of ASICs and BFL will fall flat on shipping before anyone else.

Luke-Jr. said if I asked him nicely enough he'd code us a quick 51% attack client for TerraCoin.

Anyone in?

[1)]

I don't have time to actually make this, but this is my proposal:

MEMCOIN PROTOCOL

1) Difficulty adjustment rate 3.5 days with the generation of 2016 blocks.  Other properties regarding difficulty adjustment are also the same as for Litecoin.

2) Blockreward begins at 50 coins and decreases every 35 days (10 difficulty periods) according to the following formula:
reward = previous_reward * (1+(-0.07/10))^(10*0.10)
This leads to a 7% decrease in blockreward every 350 days, or a blockreward halving in a little under 10 years.
Finance/business people will recognize this as the formula for compounded interest.

3) Scrypt is used with the following scheme:
1. ChaCha20 for mix algorithm, because it's a little faster than Salsa20.
2. SHA256 followed by BLAKE256 followed by keccak256 (SHA3-256) for the crypt algorithm, to enhance circuit size in ASICs without strongly affecting hash speed.  This should make memcoin more ASIC unfriendly.

and the following variables:
N = 1024
p = 1
r = variable

3.1) The scrypt parameter r is initialized as 128, so the initial memory required per scrypt process is 16 MB.  The value of r will be multiplied by 3.5 every 1050 days (604800), e.g., a little less than 3 years after chain creation r will be 448 and the required memory will be 56 MB per thread.  This is in keeping with Moore's law, and should ensure that the chain remains CPU/GPU-minable for a long time.

Things to be done from a Litecoin fork:
- Modification of scrypt miners to accept variable values of r and to utilize the new scrypt algorithm proposed (see https://github.com/floodyberry/scrypt-jane for different scrypt implementations)
- Adding the variable r to each block
- Implementing the new blockreward algorithm

Benefits of the chain:
- Long implementation time for blockreward decrease, so blockreward will not be ~1.5 for 50 years.
- Progressive stepping for blockreward decreases of a little over a month
- Very FPGA and ASIC difficult because of the massive memory requirements and large circuit size for cryptography algorithms, so CPUs/GPUs will be ideal for mining

Release: Upon the building of the final binary of the bitcoin-qt and cpuminer fork from the source code, a couple extra blocks will be mined to ensure the binaries are functional and then the binaries and source will be compressed and encrypted in a 7zip file with 256-bit AES.  This encrypted file will be uploaded on multiupload and as a torrent one week before the chain is to launch.  Upon the launch date, a password will be revealed and everyone can begin mining the chain at the same time.

Thoughts?

CURRENT DEVELOPER BOUNTY: 0 BTC
ADDRESS TO DONATE TO DEVELOPER BOUNTY: 1DSbmKcWrir5zxXPZhjjZdVLsqLZxu2Qc4

DEVELOPER BOUNTY WILL BE AWARDED TO THE FIRST PERSON OR GROUP TO FULLY IMPLEMENT THE PROTOCOL.  PREMINES, IF ADDED BY THE DEVELOPER, WILL BE REMOVED PRIOR TO LAUNCH BY MODIFICATION OF THE GENESIS BLOCK.

edit: Forgot to change to 7% decrease, fixed (lots of 3.5s and multiples in this protocol)

PM me if interested in the development.

Edit:  Closing this because the CUDA source code wasn't published yet, despite the paper being two years old...  You'd probably find this pretty hard to do without it.

As in title,

Want a 6950 shipped to my address in Canada for $150 USD/CAD PP, LTC, or BTC.

Must accept escrow from a trusted forum member.

edit: fulfilled