Search content
Sort by
Showing 20 of 71 results by Vinz87
Hi,
I read about technical rules for transaction fees in the official bitcoin wiki, where there's written:
Sending
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
The "technical info section" below explain how to compute the "Priority", and that it has to be greater than 57600000.
Now I want to build a raw transaction and I want to know if it can be safely propagated without fees.
I did the math with all the unspent outputs I would take coins from, and it results in a priority of only 3.6M.
Moreover, I tried to build the raw transaction, and it would consist of 2972 hex characters, or 1486 bytes.
There will be only one output of 0.01 BTC.
So what I ask is: can I wait until the unspent outputs will be older enough to yield a priority greater than 57.6M, and send the transaction with 0 fees even if its size is greater than 1kB?
Or, since I am not under the size limit, a 0.0001 (or 0.0002?) BTC fee is required for a 1500 bytes transaction, regardless of the calculated priority?
Thanks
I read about technical rules for transaction fees in the official bitcoin wiki, where there's written:
Sending
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
The "technical info section" below explain how to compute the "Priority", and that it has to be greater than 57600000.
Now I want to build a raw transaction and I want to know if it can be safely propagated without fees.
I did the math with all the unspent outputs I would take coins from, and it results in a priority of only 3.6M.
Moreover, I tried to build the raw transaction, and it would consist of 2972 hex characters, or 1486 bytes.
There will be only one output of 0.01 BTC.
So what I ask is: can I wait until the unspent outputs will be older enough to yield a priority greater than 57.6M, and send the transaction with 0 fees even if its size is greater than 1kB?
Or, since I am not under the size limit, a 0.0001 (or 0.0002?) BTC fee is required for a 1500 bytes transaction, regardless of the calculated priority?
Thanks
To get quickly included in the block, it is always preferable to add at least 0.0001 BTC, however small your Tx size is...
So:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below) -> greater than 57600000
all these 3 conditions have to be met in order to send a transaction with zero fees? Is it correct?
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below) -> greater than 57600000
all these 3 conditions have to be met in order to send a transaction with zero fees? Is it correct?
Hi,
I read about technical rules for transaction fees in the official bitcoin wiki, where there's written:
Sending
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
The "technical info section" below explain how to compute the "Priority", and that it has to be greater than 57600000.
Now I want to build a raw transaction and I want to know if it can be safely propagated without fees.
I did the math with all the unspent outputs I would take coins from, and it results in a priority of only 3.6M.
Moreover, I tried to build the raw transaction, and it would consist of 2972 hex characters, or 1486 bytes.
There will be only one output of 0.01 BTC.
So what I ask is: can I wait until the unspent outputs will be older enough to yield a priority greater than 57.6M, and send the transaction with 0 fees even if its size is greater than 1kB?
Or, since I am not under the size limit, a 0.0001 (or 0.0002?) BTC fee is required for a 1500 bytes transaction, regardless of the calculated priority?
Thanks
I read about technical rules for transaction fees in the official bitcoin wiki, where there's written:
Sending
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
The "technical info section" below explain how to compute the "Priority", and that it has to be greater than 57600000.
Now I want to build a raw transaction and I want to know if it can be safely propagated without fees.
I did the math with all the unspent outputs I would take coins from, and it results in a priority of only 3.6M.
Moreover, I tried to build the raw transaction, and it would consist of 2972 hex characters, or 1486 bytes.
There will be only one output of 0.01 BTC.
So what I ask is: can I wait until the unspent outputs will be older enough to yield a priority greater than 57.6M, and send the transaction with 0 fees even if its size is greater than 1kB?
Or, since I am not under the size limit, a 0.0001 (or 0.0002?) BTC fee is required for a 1500 bytes transaction, regardless of the calculated priority?
Thanks
can someone help me? I'm on OS X 10.9, I have gcc 4.5 installed via homebrew, now I have to install the dependencies this software relies on, should I use homebrew as well?
but for example I get this error
but for example I get this error
Code:
$ brew install libssl-dev
Error: No available formula for libssl-dev
Error: No available formula for libssl-dev
Re: A bitcoin blockchain parser in a few (thousand) lines of C++
is this topic alive? i'm trying to compile your software with gcc 4.5 on OS X Mavericks, but I get these errors:
Code:
$ gcc *.cpp -o blockchain.out
BlockChain.cpp:2619:11: warning: enumeration value 'AM_LAST' not handled in switch [-Wswitch]
switch ( m )
^
1 warning generated.
main.cpp:320:116: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...%d bitcoin addresses with a balance of more than %d bitcoins.\r\n", tcount, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:334:109: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...oldest bitcoin addresses with a balance of more than %d bitcoins.\r\n", tcount, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:348:124: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...older than %d days with a balance of more than %d bitcoins.\r\n", zdays, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:418:17: warning: enumeration value 'SR_LAST' not handled in switch [-Wswitch]
switch ( mStatResolution )
^
main.cpp:394:12: warning: enumeration values 'CM_NONE' and 'CM_EXIT' not handled in switch [-Wswitch]
switch ( mMode )
^
5 warnings generated.
Undefined symbols for architecture x86_64:
"std::__1::__vector_base_common::__throw_length_error() const", referenced from:
void std::__1::vector >::__push_back_slow_path(BlockChainAddresses::StatAddress const&) in BlockChainAddresses-837c2d.o
"std::terminate()", referenced from:
___clang_call_terminate in BlockChain-69c2db.o
___clang_call_terminate in BlockChainAddresses-837c2d.o
___clang_call_terminate in main-b5bd23.o
"vtable for __cxxabiv1::__class_type_info", referenced from:
typeinfo for BlockChain in BlockChain-69c2db.o
typeinfo for QuickSortPointers in BlockChain-69c2db.o
typeinfo for BlockChainAddresses in BlockChainAddresses-837c2d.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"vtable for __cxxabiv1::__si_class_type_info", referenced from:
typeinfo for BlockChainImpl in BlockChain-69c2db.o
typeinfo for SortByAge in BlockChain-69c2db.o
typeinfo for SortByBalance in BlockChain-69c2db.o
typeinfo for BlockChainAddressesImpl in BlockChainAddresses-837c2d.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"operator delete[](void*)", referenced from:
SimpleHash::init() in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
BitcoinTransactionFactory::printOldest(unsigned int, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::printTopBalances(unsigned int, float) in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::saveStatistics(bool, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::saveAddressesOverTime() in BlockChain-69c2db.o
...
"operator delete(void*)", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
createBlockChainAddresses(char const*) in BlockChainAddresses-837c2d.o
BlockChainAddressesImpl::~BlockChainAddressesImpl() in BlockChainAddresses-837c2d.o
std::__1::__vector_base >::~__vector_base() in BlockChainAddresses-837c2d.o
std::__1::__split_buffer&>::~__split_buffer() in BlockChainAddresses-837c2d.o
BlockChainAddresses::~BlockChainAddresses() in BlockChainAddresses-837c2d.o
...
"operator new[](unsigned long)", referenced from:
BlockChainImpl::buildBlockChain() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::printOldest(unsigned int, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::printTopBalances(unsigned int, float) in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::saveStatistics(bool, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::saveAddressesOverTime() in BlockChain-69c2db.o
...
"operator new(unsigned long)", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
createBlockChainAddresses(char const*) in BlockChainAddresses-837c2d.o
std::__1::__split_buffer&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator&) in BlockChainAddresses-837c2d.o
"___cxa_begin_catch", referenced from:
___clang_call_terminate in BlockChain-69c2db.o
___clang_call_terminate in BlockChainAddresses-837c2d.o
___clang_call_terminate in main-b5bd23.o
"___cxa_pure_virtual", referenced from:
vtable for QuickSortPointers in BlockChain-69c2db.o
vtable for BlockChain in BlockChain-69c2db.o
vtable for BlockChainAddresses in BlockChainAddresses-837c2d.o
"___gxx_personality_v0", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
BlockChainImpl::BlockChainImpl(char const*) in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::gatherStatistics(unsigned int, unsigned int, bool) in BlockChain-69c2db.o
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
BlockChain.cpp:2619:11: warning: enumeration value 'AM_LAST' not handled in switch [-Wswitch]
switch ( m )
^
1 warning generated.
main.cpp:320:116: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...%d bitcoin addresses with a balance of more than %d bitcoins.\r\n", tcount, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:334:109: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...oldest bitcoin addresses with a balance of more than %d bitcoins.\r\n", tcount, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:348:124: warning: format specifies type 'int' but the argument has type 'float' [-Wformat]
...older than %d days with a balance of more than %d bitcoins.\r\n", zdays, mMinBalance );
~~ ^~~~~~~~~~~
%f
main.cpp:418:17: warning: enumeration value 'SR_LAST' not handled in switch [-Wswitch]
switch ( mStatResolution )
^
main.cpp:394:12: warning: enumeration values 'CM_NONE' and 'CM_EXIT' not handled in switch [-Wswitch]
switch ( mMode )
^
5 warnings generated.
Undefined symbols for architecture x86_64:
"std::__1::__vector_base_common::__throw_length_error() const", referenced from:
void std::__1::vector >::__push_back_slow_path(BlockChainAddresses::StatAddress const&) in BlockChainAddresses-837c2d.o
"std::terminate()", referenced from:
___clang_call_terminate in BlockChain-69c2db.o
___clang_call_terminate in BlockChainAddresses-837c2d.o
___clang_call_terminate in main-b5bd23.o
"vtable for __cxxabiv1::__class_type_info", referenced from:
typeinfo for BlockChain in BlockChain-69c2db.o
typeinfo for QuickSortPointers in BlockChain-69c2db.o
typeinfo for BlockChainAddresses in BlockChainAddresses-837c2d.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"vtable for __cxxabiv1::__si_class_type_info", referenced from:
typeinfo for BlockChainImpl in BlockChain-69c2db.o
typeinfo for SortByAge in BlockChain-69c2db.o
typeinfo for SortByBalance in BlockChain-69c2db.o
typeinfo for BlockChainAddressesImpl in BlockChainAddresses-837c2d.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"operator delete[](void*)", referenced from:
SimpleHash::init() in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
BitcoinTransactionFactory::printOldest(unsigned int, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::printTopBalances(unsigned int, float) in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::saveStatistics(bool, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::saveAddressesOverTime() in BlockChain-69c2db.o
...
"operator delete(void*)", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
createBlockChainAddresses(char const*) in BlockChainAddresses-837c2d.o
BlockChainAddressesImpl::~BlockChainAddressesImpl() in BlockChainAddresses-837c2d.o
std::__1::__vector_base >::~__vector_base() in BlockChainAddresses-837c2d.o
std::__1::__split_buffer&>::~__split_buffer() in BlockChainAddresses-837c2d.o
BlockChainAddresses::~BlockChainAddresses() in BlockChainAddresses-837c2d.o
...
"operator new[](unsigned long)", referenced from:
BlockChainImpl::buildBlockChain() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::printOldest(unsigned int, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::printTopBalances(unsigned int, float) in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::saveStatistics(bool, float) in BlockChain-69c2db.o
BitcoinTransactionFactory::saveAddressesOverTime() in BlockChain-69c2db.o
...
"operator new(unsigned long)", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
createBlockChainAddresses(char const*) in BlockChainAddresses-837c2d.o
std::__1::__split_buffer&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator&) in BlockChainAddresses-837c2d.o
"___cxa_begin_catch", referenced from:
___clang_call_terminate in BlockChain-69c2db.o
___clang_call_terminate in BlockChainAddresses-837c2d.o
___clang_call_terminate in main-b5bd23.o
"___cxa_pure_virtual", referenced from:
vtable for QuickSortPointers in BlockChain-69c2db.o
vtable for BlockChain in BlockChain-69c2db.o
vtable for BlockChainAddresses in BlockChainAddresses-837c2d.o
"___gxx_personality_v0", referenced from:
createBlockChain(char const*) in BlockChain-69c2db.o
BlockChainImpl::BlockChainImpl(char const*) in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BlockChainImpl::~BlockChainImpl() in BlockChain-69c2db.o
SimpleHash::init() in BlockChain-69c2db.o
BitcoinTransactionFactory::gatherStatistics(unsigned int, unsigned int, bool) in BlockChain-69c2db.o
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Update: the transaction was broadcasted through blockchain.info API, and after 2 days I received an email from them saying they will cancel the transaction since it is not going to be confirmed.
My watch-only Electrum wallet still has it pending in transactions history.
When, and how, will I know that those coins are again in my sending address and I'm able to spend them in another transaction?
My watch-only Electrum wallet still has it pending in transactions history.
When, and how, will I know that those coins are again in my sending address and I'm able to spend them in another transaction?
Re: New profit-switching mining pool with nightly bonus payout-- CoinSolver.com
Can someone explain me how the payouts work for small btc amounts?
I read that if the balance is under 0.01 you will be payed after 3 days if there is no mining activity.
Does it mean that if mine everyday I won't be payed every 3 days for an amount under 0.01, but only when the balance reaches 0.01?
I read that if the balance is under 0.01 you will be payed after 3 days if there is no mining activity.
Does it mean that if mine everyday I won't be payed every 3 days for an amount under 0.01, but only when the balance reaches 0.01?
Once you hit 0.01 you get a payout that night. If you do not mine for 3 days, you will get paid out whatever is in your balance.
Hi all, I was playing with raw transactions just for fun, so I managed to generate a transaction between two wallets of mine of 5640 satoshi (the minimum amount which should be accepted by the network), without fees.
I finally broadcasted the transaction and all seems fine with the transaction itself.
Now, as it was predictable, the transaction doesn't get confirmed. It was broadcasted 48 hours ago. What I want to ask to someone more experienced than me is:
1) is there at all the possibility that the transaction will eventually be confirmed?
2) in the meanwhile, that tiny btc amount is someway freezed? Am I able to spend them again (i.e. to use them from the same "unspent output" I picked them in order to build a new transaction)? Or they already belong to the new address and I will be able to spend them only from that new address and only if and when the transaction will be confirmed?
3) does the transaction priority would have changed, even minimally, if I had included a 1 satoshi fee in the transaction? or the amount of fees is not important until they don't reach the "suggested" value?
Thanks
I finally broadcasted the transaction and all seems fine with the transaction itself.
Now, as it was predictable, the transaction doesn't get confirmed. It was broadcasted 48 hours ago. What I want to ask to someone more experienced than me is:
1) is there at all the possibility that the transaction will eventually be confirmed?
2) in the meanwhile, that tiny btc amount is someway freezed? Am I able to spend them again (i.e. to use them from the same "unspent output" I picked them in order to build a new transaction)? Or they already belong to the new address and I will be able to spend them only from that new address and only if and when the transaction will be confirmed?
3) does the transaction priority would have changed, even minimally, if I had included a 1 satoshi fee in the transaction? or the amount of fees is not important until they don't reach the "suggested" value?
Thanks
Re: New profit-switching mining pool with nightly bonus payout-- CoinSolver.com
Can someone explain me how the payouts work for small btc amounts?
I read that if the balance is under 0.01 you will be payed after 3 days if there is no mining activity.
Does it mean that if mine everyday I won't be payed every 3 days for an amount under 0.01, but only when the balance reaches 0.01?
I read that if the balance is under 0.01 you will be payed after 3 days if there is no mining activity.
Does it mean that if mine everyday I won't be payed every 3 days for an amount under 0.01, but only when the balance reaches 0.01?
Re: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com
What is hashcows mining that they are making .0142BTC/Mh... they're killing it. Middlecoin has died though, 0.0036... ouch
actually this is not what hashcows users say on their bitcointalk thread...Re: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com
what about vardiff? i read that it was enabled in the recent past and then the pool switched to a fixed diff=512. will we be able in the future to mine at vardiff with low end miners or to choose the diff by ourself?
Re: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com
This thing has already been applied several times:
so they are shares that i actually lost? or they may be eventually accepted and i will see that number lowering?Quote
When cgminer sends shares via stratum, it does not send the share and then wait for the response as this might slow down the sending of other shares. This means that the response back from the pool is processed separately from the share submission (to make the most of a truly multithreaded environment). However there is never a guarantee that the responses come back in the same order you send them. So cgminer stores a copy of each share as it sends it to the server in its own local database of submitted shares. When it gets a response back about that share from the pool, it deletes the copy of that share. Now stratum is meant to be an uninterrupted connection to the pool, and if you lose that connection, it is assumed that your "session" is no longer valid. So if you send some shares and get disconnected before you get a response, cgminer has to assume that those shares have been lost - otherwise it may end up keeping copies of heaps of shares that it will never get a response to and wastes memory. If you manage to reconnect, sometimes the pool will actually tell you "oh by the way those shares are ok" - however cgminer has now thrown out the record of what those shares were and can only say that the pool said a share was accepted or rejected. Then cgminer just says it's an "untracked share"." (c) ckolivas
Re: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com
What does "Rejected untracked stratum share" mean?
cgminer version 3.5.0 - Started: [2014-02-19 10:56:44]
--------------------------------------------------------------------------------
(5s):51.20K (avg):51.35Kh/s | A:512 R:14848 HW:0 WU:45.8/m
ST: 1 SS: 0 NB: 82 LW: 333 GF: 0 RF: 0
Connected to us.clevermining.com diff 512 with stratum as user
Block: dbfbf5624d7fff06... Diff:13.3M Started: [11:14:58] Best share: 1.77K
--------------------------------------------------------------------------------
[P]ool management [G]PU management ettings [D]isplay options [Q]uit
GPU 0: | 51.08K/51.35Kh/s | A:512 R:1024 HW:0 WU: 45.8/m I:12
--------------------------------------------------------------------------------
[2014-02-19 11:14:37] Stratum from pool 0 detected new block
[2014-02-19 11:14:49] Rejected untracked stratum share from pool 0
[2014-02-19 11:14:49] Network diff set to 851K
[2014-02-19 11:14:49] Stratum from pool 0 detected new block
[2014-02-19 11:14:51] Network diff set to 932K
[2014-02-19 11:14:51] Stratum from pool 0 detected new block
[2014-02-19 11:14:53] Network diff set to 989K
[2014-02-19 11:14:53] Stratum from pool 0 detected new block
[2014-02-19 11:14:58] Rejected untracked stratum share from pool 0
[2014-02-19 11:14:58] Network diff set to 13.3M
[2014-02-19 11:14:58] Stratum from pool 0 detected new block
they are counted in the first row (R:14848), but not in the GPU stats (R:1024).
this are my settings:
./cgminer --scrypt -o stratum+tcp://us.clevermining.com:3333 -u -p x -g 1 -w 64 -I 12 --queue 0
cgminer version 3.5.0 - Started: [2014-02-19 10:56:44]
--------------------------------------------------------------------------------
(5s):51.20K (avg):51.35Kh/s | A:512 R:14848 HW:0 WU:45.8/m
ST: 1 SS: 0 NB: 82 LW: 333 GF: 0 RF: 0
Connected to us.clevermining.com diff 512 with stratum as user
Block: dbfbf5624d7fff06... Diff:13.3M Started: [11:14:58] Best share: 1.77K
--------------------------------------------------------------------------------
[P]ool management [G]PU management ettings [D]isplay options [Q]uit
GPU 0: | 51.08K/51.35Kh/s | A:512 R:1024 HW:0 WU: 45.8/m I:12
--------------------------------------------------------------------------------
[2014-02-19 11:14:37] Stratum from pool 0 detected new block
[2014-02-19 11:14:49] Rejected untracked stratum share from pool 0
[2014-02-19 11:14:49] Network diff set to 851K
[2014-02-19 11:14:49] Stratum from pool 0 detected new block
[2014-02-19 11:14:51] Network diff set to 932K
[2014-02-19 11:14:51] Stratum from pool 0 detected new block
[2014-02-19 11:14:53] Network diff set to 989K
[2014-02-19 11:14:53] Stratum from pool 0 detected new block
[2014-02-19 11:14:58] Rejected untracked stratum share from pool 0
[2014-02-19 11:14:58] Network diff set to 13.3M
[2014-02-19 11:14:58] Stratum from pool 0 detected new block
they are counted in the first row (R:14848), but not in the GPU stats (R:1024).
this are my settings:
./cgminer --scrypt -o stratum+tcp://us.clevermining.com:3333 -u -p x -g 1 -w 64 -I 12 --queue 0
Re: [ANN] profit switching auto-exchanging pool - www.middlecoin.com
All jokes aside am I the only one who didn't receive a payout today?
I am over the 0.01 BTC threshold. Here is my chart: http://middlecoin.info/flotchart.php?BTC=1DqFB2bvP2w8PgwXCMfweLWwApGgevF4VB
I didn't get the last payout at 2/15/2014.
Anyone else?
I am over the 0.01 BTC threshold. Here is my chart: http://middlecoin.info/flotchart.php?BTC=1DqFB2bvP2w8PgwXCMfweLWwApGgevF4VB
I didn't get the last payout at 2/15/2014.
Anyone else?
Still waiting for the payout to arrive in my wallet
There is a transaction ID associated with our payouts so I don't know where the Bottleneck is on the BitCoin network.
Any ideas, anyone?