Bitcoin Forum
November 05, 2024, 04:15:13 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 [166] 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 ... 265 »
  Print  
Author Topic: Official Anoncoin chat thread (including history)  (Read 530651 times)
varun555
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
October 11, 2014, 09:39:28 AM
 #3301


That's thanks for support to SDC from one of our member??
I see few of you splits 6.5M SDC in few weeks, yeah, troll around for your free BTC!

https://bitcointalk.org/index.php?topic=583449.msg9149065#msg9149065


Hi Anoncoin,

Don't feed these trolls they are not affiliated with Shadow. We respect the development going on here and wish you all the best.



Hahahahahaha........ Nice one!
mathgal23
Full Member
***
Offline Offline

Activity: 150
Merit: 102


View Profile
October 11, 2014, 10:54:03 AM
 #3302

http://forum.bleutrade.com/index.php/topic,40.0.html

POSSIBLE ANONCOIN BUG REPORT

Hi. Today we are faced with a problem reported by some Bleutrade users that withdraw his was not working. We found it strange being our lasts withdraws with 0 confirmations. We decided to investigate.

::::: Normal Withdraw Today :::::

    {
        "account" : "",
        "address" : "ALvNv6ydiqNuey129MXJV4tywqBPn9USyW",
        "category" : "send",
        "amount" : -47.78000000,
        "fee" : 0.00000000,
        "confirmations" : 0,
        "txid" : "0013dd6a25d222ceb203b1977d60a7db5f6f9b91c1c186f65517b29abcc8dfbc",
        "time" : 1412854096,
        "timereceived" : 1412854096,
        "comment" : "b w17686 e4050480",
        "to" : "b w17686 e4050480"
    },

0 confirmations? why?...

This transaction also does not appear in explorer. hmm... ok, let's investigate...

For this example, we will use a normal transaction in the original wallet (Another Normal Withdraw, days ago):

    {
        "account" : "",
        "address" : "ASz5NtGjBRjHoP2RPqeCAEcbvm1KC3xwcx",
        "category" : "send",
        "amount" : -446.11059087,
        "fee" : 0.00000000,
        "confirmations" : 65164,
        "blockhash" : "7f5310f1bab45d6157fb4fc00d0f440f1d5db5c6b4d689e72118dce046373512",
        "blockindex" : 2,
        "blocktime" : 1401023096,
        "txid" : "df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07",
        "time" : 1401022562,
        "timereceived" : 1401022562,
        "comment" : "b w2721 e126667",
        "to" : "b w2721 e126667"
    },

First step to test, creating a new wallet.dat with all existing addresses and privkeys.

After RESCAN and REINDEX and CHECKBLOCKS etc..:

:::: SURPRISE :::::

The transaction of example disappears and this appears:

    {
        "account" : "",
        "address" : "AMwxitA4zzi54Ax2kngNnvw8nGChwBDQuh",
        "category" : "send",
        "amount" : -757.03044568,
        "fee" : 0.00000000,
        "confirmations" : 65193,
        "blockhash" : "bc31fcc6c5c333e7efdaadbd088e6873a7e7c7c9007444feccd0b8bb4dc321dc",
        "blockindex" : 1,
        "blocktime" : 1401017947,
        "txid" : "deef70d946477552db8b70aac87fe16a5eb06767fd6668e6e00bca3f4ffceb2c",
        "time" : 1401017947,
        "timereceived" : 1412871290
    },

http://ancblockchain.com/tx/df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07

"AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J(310.91985481 ANC - Unspent)" - Anonymizer? ok, but...

Our ORIGINAL wallet.dat does not contain the private key or another key or path of 'AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J'!!!

This is the explanation for non-confirmations of the lasts withdraws. The Blockchain not recognize this and other addresses. Was forgotten in time. This may not have been affected by a forked block, because it is an old transaction.

We can not trust the current app, we does not understand because on send 446.11059087, 310.91985481 ANC lost to a arbitrary nonexistent address in a original wallet.dat! The application is not storing correctly the private keys of anonymizer addresses.

Final Thoughts

We ask immediately withdraw their ANCs from Bleutrade. We do not know what may happen in the future, because this app is not updated over 1 year. We believe that there may exist bug in a hidden zero coin system that does not properly stores the transactions wallet.dat file. Sorry for the inconvenience.

Best regards,

Felipe McMont
COO/CTO & Co-Founder
Bleutrade.com

OK. Seems bleutrade is dead now too. They are even more stupid than craptsy...

One solution would just be to hold ANC and not trade it at all (on either Bleutrade or Cryptsy) right now. Hopefully the upcoming hard fork will fix all the issues above. If Zerocoin beta goes well then valuation may end up being a lot higher after the mining difficulty problems are fixed.  At that point it should be safe to send ANC to/from the exchanges again
varun555
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
October 11, 2014, 11:14:33 AM
 #3303


Awesome.  Looks like they are fixing the diff. algo before ZC implementation. Smart move.
Informed  anc.cryptotroll.com pool....... any ETA on the upgrade yet ?
mathgal23
Full Member
***
Offline Offline

Activity: 150
Merit: 102


View Profile
October 11, 2014, 11:19:15 AM
 #3304

Yes, that is my understanding exactly, except I have read over and over that it is only possible to generate trustless parameters with zerocoin, not zerocash.  Do you have a source that states it is possible with zerocash?

I am just going off of what they have stated on Twitter. Along with the following statements, they have mentioned the ability to generate the parameters by using multi party computations.. which is basically what the rsa ufo project is doing with ZeroCoin. If you look through their statements on Twitter it doesn't sound much different than they way Anoncoin is computing the ZeroCoin accumulator.

Re: Trust required for Zerocash setup





Maybe I am naive, but I think they will find a way to setup Zerocash that people will be able to trust.

Well that is interesting, But I think unless they are able to pool hundreds of people to publicly generate the parameters in a trustless manner I kind of doubt the darknetmarket people will use zerocash over zerocoin.  I'm willing to bet money they would trust meeh over matt green et al.

I think meeh, gnosis, Ian Miers and Matt Green are all trustworthy.  That being said aside from first mover advantage I think we all see our trustless RSA UFO project as our key advantage over a Zerocash setup that requires trust.

If Zerocash finds a way to become truly trustless then we lose that advantage.  As of right now it still sounds like Zerocash will require some element of trust in parameter generation.
LucyLovesCrypto
Sr. Member
****
Offline Offline

Activity: 414
Merit: 251


View Profile
October 11, 2014, 12:44:51 PM
 #3305

http://forum.bleutrade.com/index.php/topic,40.0.html

POSSIBLE ANONCOIN BUG REPORT

Hi. Today we are faced with a problem reported by some Bleutrade users that withdraw his was not working. We found it strange being our lasts withdraws with 0 confirmations. We decided to investigate.

::::: Normal Withdraw Today :::::

    {
        "account" : "",
        "address" : "ALvNv6ydiqNuey129MXJV4tywqBPn9USyW",
        "category" : "send",
        "amount" : -47.78000000,
        "fee" : 0.00000000,
        "confirmations" : 0,
        "txid" : "0013dd6a25d222ceb203b1977d60a7db5f6f9b91c1c186f65517b29abcc8dfbc",
        "time" : 1412854096,
        "timereceived" : 1412854096,
        "comment" : "b w17686 e4050480",
        "to" : "b w17686 e4050480"
    },

0 confirmations? why?...

This transaction also does not appear in explorer. hmm... ok, let's investigate...

For this example, we will use a normal transaction in the original wallet (Another Normal Withdraw, days ago):

    {
        "account" : "",
        "address" : "ASz5NtGjBRjHoP2RPqeCAEcbvm1KC3xwcx",
        "category" : "send",
        "amount" : -446.11059087,
        "fee" : 0.00000000,
        "confirmations" : 65164,
        "blockhash" : "7f5310f1bab45d6157fb4fc00d0f440f1d5db5c6b4d689e72118dce046373512",
        "blockindex" : 2,
        "blocktime" : 1401023096,
        "txid" : "df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07",
        "time" : 1401022562,
        "timereceived" : 1401022562,
        "comment" : "b w2721 e126667",
        "to" : "b w2721 e126667"
    },

First step to test, creating a new wallet.dat with all existing addresses and privkeys.

After RESCAN and REINDEX and CHECKBLOCKS etc..:

:::: SURPRISE :::::

The transaction of example disappears and this appears:

    {
        "account" : "",
        "address" : "AMwxitA4zzi54Ax2kngNnvw8nGChwBDQuh",
        "category" : "send",
        "amount" : -757.03044568,
        "fee" : 0.00000000,
        "confirmations" : 65193,
        "blockhash" : "bc31fcc6c5c333e7efdaadbd088e6873a7e7c7c9007444feccd0b8bb4dc321dc",
        "blockindex" : 1,
        "blocktime" : 1401017947,
        "txid" : "deef70d946477552db8b70aac87fe16a5eb06767fd6668e6e00bca3f4ffceb2c",
        "time" : 1401017947,
        "timereceived" : 1412871290
    },

http://ancblockchain.com/tx/df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07

"AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J(310.91985481 ANC - Unspent)" - Anonymizer? ok, but...

Our ORIGINAL wallet.dat does not contain the private key or another key or path of 'AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J'!!!

This is the explanation for non-confirmations of the lasts withdraws. The Blockchain not recognize this and other addresses. Was forgotten in time. This may not have been affected by a forked block, because it is an old transaction.

We can not trust the current app, we does not understand because on send 446.11059087, 310.91985481 ANC lost to a arbitrary nonexistent address in a original wallet.dat! The application is not storing correctly the private keys of anonymizer addresses.

Final Thoughts

We ask immediately withdraw their ANCs from Bleutrade. We do not know what may happen in the future, because this app is not updated over 1 year. We believe that there may exist bug in a hidden zero coin system that does not properly stores the transactions wallet.dat file. Sorry for the inconvenience.

Best regards,

Felipe McMont
COO/CTO & Co-Founder
Bleutrade.com

OK. Seems bleutrade is dead now too. They are even more stupid than craptsy...

Actually Cryptsy thinks its is our fault
https://bitcointalk.org/index.php?topic=227287.msg8869037#msg8869037

Quote from mullick (Cryptsy):

"Ok lets clear this up once and for all.

I have NOT modified our daemon in anyway. We have built directly from source with no changes. Anoncoind is creating these transaction and paying the large fee required. yet they are not being accepted into the chain. As you can see by my previous post."

Quote from: mullick on August 14, 2014, 07:45:14 PM
Hello everyone,

Im currently investigating an issue with our ANC wallet where the blockchain isnt picking up the majority of our send transactions. We apologize it took us so long to spot the issue. But we are working hard on correcting it and getting the unconfirmed transactions pushed to the blockchain

Some of them get confirmed after a simple restart of the daemon but others do not/ Ill keep everyone informed when I find the solution

Thank you for your patience Smiley

UPDATE:

I think it comes down to transaction sizes. Our daemon is sending transactions that are too large to be accpeted into the chain. Im basing this on the fact that all unconfirmed send transactions have unusually high fees paid. Our default Txfee is .01 ANC and the mean over the last 1000 transactions is 0.10169169169169 which is why our withdrawal fee is set to .1 ANC

Code:

anoncoind listtransactions "" 1000 | grep -A 1 -B 4 '"confirmations" : 0,' | grep fee
        "fee" : -0.82000000,
        "fee" : -0.90000000,
        "fee" : -0.98000000,
        "fee" : -0.65000000,
        "fee" : -0.69000000,
        "fee" : -0.72000000,
        "fee" : -0.74000000,
        "fee" : -0.76000000,
        "fee" : -0.77000000,
        "fee" : -0.81000000,
        "fee" : -1.00000000,
        "fee" : -0.68000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.76000000,
        "fee" : -0.76000000,
        "fee" : -0.77000000,
        "fee" : -0.77000000,
        "fee" : -0.77000000,
        "fee" : -0.78000000,
        "fee" : -0.79000000,
        "fee" : -0.85000000,
        "fee" : -0.96000000,
        "fee" : -0.64000000,
        "fee" : -0.66000000,
        "fee" : -0.67000000,
        "fee" : -0.69000000,
        "fee" : -0.71000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.77000000,
        "fee" : -0.79000000,
        "fee" : -0.84000000,
        "fee" : -0.87000000,
        "fee" : -0.92000000,
        "fee" : -0.95000000,
        "fee" : -0.98000000,
        "fee" : -0.63000000,
        "fee" : -0.64000000,
        "fee" : -0.65000000,
        "fee" : -0.66000000,
        "fee" : -0.68000000,
        "fee" : -0.68000000,
        "fee" : -0.69000000,
        "fee" : -0.70000000,
        "fee" : -0.71000000,
        "fee" : -0.71000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.76000000,
        "fee" : -0.78000000,
        "fee" : -0.80000000,
        "fee" : -0.83000000,
        "fee" : -0.88000000,
        "fee" : -0.92000000,
        "fee" : -0.99000000,
        "fee" : -0.98000000,
        "fee" : -0.97000000,
        "fee" : -0.87000000,
        "fee" : -0.81000000,
        "fee" : -0.86000000,


Our daemon is up to date so ill be going over the source to see if I can find anything that would cause this

As you can see from my request to the daemon:

Code:

anoncoind listtransactions "" 1000 | grep -A 1 -B 4 '"confirmations" : 0,' | grep fee


I grabbed the last 1000 transactions and searched for any with "confirmations" : 0, and grabbed the fee for the transaction.

All of the unconfirmed transactions in our wallet paid a high fee suggesting its due to block size.

To counteract this until the issue is resolved by the developers i have merged any input in our wallet less than .1 anc ( about 50k of them ) into inputs over 1 ANC. These may have broken down to some smaller ones now so ill likely have to run it again

Here are some others with the same problem

Quote from: shtako on August 23, 2014, 07:57:45 AM
Quote from: SmokingSkull on August 21, 2014, 07:50:06 PM
Same Problem.

It makes me mad all the time  Angry

And It's not good at all for beginners who want to buy into ANC when there are problems with Buying and Withdrawing.

Same problem. Tried to withdraw from bleutrade 2 days ago and the transaction still havent gone trough. To fix this should be highest priority.

Quote from: niteglider on August 22, 2014, 11:31:12 PM
Quote from: TCB4728 on August 21, 2014, 06:32:52 PM
Anyone else with the following problems with ANC?  My multipool operator sent earned ANC to me on August 18 at 2:01AM CDT, was not received and posted to my wallet until August 21 at 13:58 CDT.  The multipool operator states:  "The transaction hasn't been included in a block yet.  It should make it into a block eventually and be confirmed.  I have no control over this.  It's been an ongoing issue with the ANC network for a few weeks now."  That would seem to be a very strong negative against this coin.




Yes, I am on the anonmining.com pool and it took a couple of days for an autotransfer to actually post to my wallet.

It was only 5 ANCs.

What gives?

In conclusion this is not a problem with cryptsy or "craptsy" as it is being called. It seems meeh and k1773R are aware and getting these transactions to confirm eventually so i see no reason to suspend the wallet as suggested above"
newb4now
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500


View Profile
October 11, 2014, 01:07:49 PM
 #3306

xpool.net is now operating on donations.

Zero Fees!

I get webpage not found when I click the anoncoin link Sad

The link seems to be working now.

Can anyone comment about the reliability of this pool?
tljenson
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
October 11, 2014, 02:05:12 PM
 #3307

"ANON"coin...what a joke....   Cry

Get in a real coin... https://bitcointalk.org/index.php?topic=745352


I wouldn't listen to this guy. SDC completely shut down XST fourm, the dev condoned FUDing the XST thread brought the XST coin down to less than 5000 from a high of 14,000, and cost a lot of investors a lot of money. I hate to see that happen to ANONcoin, but those shadow guys are bad news. Don't feed them.
tljenson
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
October 11, 2014, 02:10:25 PM
 #3308

Here read this about SDC coin trolls and how they caused to Stealth Coin investors thousands of dollars and are trying the same bullshit in order to scare people over to ShadowCash. Don't let what happen to StealthCoin happen to you.

"STEALTHCOIN PRICE PLUMMETS AMID OVERT COMMUNITY CHAOS"

https://www.cryptocoinsnews.com/stealthcoin-price-plummets-amid-overt-community-chaos/

Theses very same trolls are Fuding your coin now. I am an investor in XST, and lost a lot of money. The reason I'm on this forum, is I am looking into other anon coins, and yours looks like a good bet.
newb4now
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500


View Profile
October 11, 2014, 02:38:03 PM
 #3309

The reason I'm on this forum, is I am looking into other anon coins, and yours looks like a good bet.

Welcome to the community. Feel free to ask any questions you would like about ANC. We have many knowledgeable users who have been around for a long time.

Our wiki page is a great place to start:
https://wiki.anoncoin.net/Anoncoin_Wiki
Simcom
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


View Profile
October 11, 2014, 02:39:46 PM
 #3310

http://forum.bleutrade.com/index.php/topic,40.0.html

POSSIBLE ANONCOIN BUG REPORT

Hi. Today we are faced with a problem reported by some Bleutrade users that withdraw his was not working. We found it strange being our lasts withdraws with 0 confirmations. We decided to investigate.

::::: Normal Withdraw Today :::::

    {
        "account" : "",
        "address" : "ALvNv6ydiqNuey129MXJV4tywqBPn9USyW",
        "category" : "send",
        "amount" : -47.78000000,
        "fee" : 0.00000000,
        "confirmations" : 0,
        "txid" : "0013dd6a25d222ceb203b1977d60a7db5f6f9b91c1c186f65517b29abcc8dfbc",
        "time" : 1412854096,
        "timereceived" : 1412854096,
        "comment" : "b w17686 e4050480",
        "to" : "b w17686 e4050480"
    },

0 confirmations? why?...

This transaction also does not appear in explorer. hmm... ok, let's investigate...

For this example, we will use a normal transaction in the original wallet (Another Normal Withdraw, days ago):

    {
        "account" : "",
        "address" : "ASz5NtGjBRjHoP2RPqeCAEcbvm1KC3xwcx",
        "category" : "send",
        "amount" : -446.11059087,
        "fee" : 0.00000000,
        "confirmations" : 65164,
        "blockhash" : "7f5310f1bab45d6157fb4fc00d0f440f1d5db5c6b4d689e72118dce046373512",
        "blockindex" : 2,
        "blocktime" : 1401023096,
        "txid" : "df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07",
        "time" : 1401022562,
        "timereceived" : 1401022562,
        "comment" : "b w2721 e126667",
        "to" : "b w2721 e126667"
    },

First step to test, creating a new wallet.dat with all existing addresses and privkeys.

After RESCAN and REINDEX and CHECKBLOCKS etc..:

:::: SURPRISE :::::

The transaction of example disappears and this appears:

    {
        "account" : "",
        "address" : "AMwxitA4zzi54Ax2kngNnvw8nGChwBDQuh",
        "category" : "send",
        "amount" : -757.03044568,
        "fee" : 0.00000000,
        "confirmations" : 65193,
        "blockhash" : "bc31fcc6c5c333e7efdaadbd088e6873a7e7c7c9007444feccd0b8bb4dc321dc",
        "blockindex" : 1,
        "blocktime" : 1401017947,
        "txid" : "deef70d946477552db8b70aac87fe16a5eb06767fd6668e6e00bca3f4ffceb2c",
        "time" : 1401017947,
        "timereceived" : 1412871290
    },

http://ancblockchain.com/tx/df1298124eb24a0b24dcd80a921e9c60578391bf7eff54241d05760976dd2d07

"AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J(310.91985481 ANC - Unspent)" - Anonymizer? ok, but...

Our ORIGINAL wallet.dat does not contain the private key or another key or path of 'AYQWQCixS4cpi4gyc8vVdmrNCzKRsm245J'!!!

This is the explanation for non-confirmations of the lasts withdraws. The Blockchain not recognize this and other addresses. Was forgotten in time. This may not have been affected by a forked block, because it is an old transaction.

We can not trust the current app, we does not understand because on send 446.11059087, 310.91985481 ANC lost to a arbitrary nonexistent address in a original wallet.dat! The application is not storing correctly the private keys of anonymizer addresses.

Final Thoughts

We ask immediately withdraw their ANCs from Bleutrade. We do not know what may happen in the future, because this app is not updated over 1 year. We believe that there may exist bug in a hidden zero coin system that does not properly stores the transactions wallet.dat file. Sorry for the inconvenience.

Best regards,

Felipe McMont
COO/CTO & Co-Founder
Bleutrade.com

OK. Seems bleutrade is dead now too. They are even more stupid than craptsy...

Actually Cryptsy thinks its is our fault
https://bitcointalk.org/index.php?topic=227287.msg8869037#msg8869037

Quote from mullick (Cryptsy):

"Ok lets clear this up once and for all.

I have NOT modified our daemon in anyway. We have built directly from source with no changes. Anoncoind is creating these transaction and paying the large fee required. yet they are not being accepted into the chain. As you can see by my previous post."

Quote from: mullick on August 14, 2014, 07:45:14 PM
Hello everyone,

Im currently investigating an issue with our ANC wallet where the blockchain isnt picking up the majority of our send transactions. We apologize it took us so long to spot the issue. But we are working hard on correcting it and getting the unconfirmed transactions pushed to the blockchain

Some of them get confirmed after a simple restart of the daemon but others do not/ Ill keep everyone informed when I find the solution

Thank you for your patience Smiley

UPDATE:

I think it comes down to transaction sizes. Our daemon is sending transactions that are too large to be accpeted into the chain. Im basing this on the fact that all unconfirmed send transactions have unusually high fees paid. Our default Txfee is .01 ANC and the mean over the last 1000 transactions is 0.10169169169169 which is why our withdrawal fee is set to .1 ANC

Code:

anoncoind listtransactions "" 1000 | grep -A 1 -B 4 '"confirmations" : 0,' | grep fee
        "fee" : -0.82000000,
        "fee" : -0.90000000,
        "fee" : -0.98000000,
        "fee" : -0.65000000,
        "fee" : -0.69000000,
        "fee" : -0.72000000,
        "fee" : -0.74000000,
        "fee" : -0.76000000,
        "fee" : -0.77000000,
        "fee" : -0.81000000,
        "fee" : -1.00000000,
        "fee" : -0.68000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.76000000,
        "fee" : -0.76000000,
        "fee" : -0.77000000,
        "fee" : -0.77000000,
        "fee" : -0.77000000,
        "fee" : -0.78000000,
        "fee" : -0.79000000,
        "fee" : -0.85000000,
        "fee" : -0.96000000,
        "fee" : -0.64000000,
        "fee" : -0.66000000,
        "fee" : -0.67000000,
        "fee" : -0.69000000,
        "fee" : -0.71000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.77000000,
        "fee" : -0.79000000,
        "fee" : -0.84000000,
        "fee" : -0.87000000,
        "fee" : -0.92000000,
        "fee" : -0.95000000,
        "fee" : -0.98000000,
        "fee" : -0.63000000,
        "fee" : -0.64000000,
        "fee" : -0.65000000,
        "fee" : -0.66000000,
        "fee" : -0.68000000,
        "fee" : -0.68000000,
        "fee" : -0.69000000,
        "fee" : -0.70000000,
        "fee" : -0.71000000,
        "fee" : -0.71000000,
        "fee" : -0.72000000,
        "fee" : -0.73000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.74000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.75000000,
        "fee" : -0.76000000,
        "fee" : -0.78000000,
        "fee" : -0.80000000,
        "fee" : -0.83000000,
        "fee" : -0.88000000,
        "fee" : -0.92000000,
        "fee" : -0.99000000,
        "fee" : -0.98000000,
        "fee" : -0.97000000,
        "fee" : -0.87000000,
        "fee" : -0.81000000,
        "fee" : -0.86000000,


Our daemon is up to date so ill be going over the source to see if I can find anything that would cause this

As you can see from my request to the daemon:

Code:

anoncoind listtransactions "" 1000 | grep -A 1 -B 4 '"confirmations" : 0,' | grep fee


I grabbed the last 1000 transactions and searched for any with "confirmations" : 0, and grabbed the fee for the transaction.

All of the unconfirmed transactions in our wallet paid a high fee suggesting its due to block size.

To counteract this until the issue is resolved by the developers i have merged any input in our wallet less than .1 anc ( about 50k of them ) into inputs over 1 ANC. These may have broken down to some smaller ones now so ill likely have to run it again

Here are some others with the same problem

Quote from: shtako on August 23, 2014, 07:57:45 AM
Quote from: SmokingSkull on August 21, 2014, 07:50:06 PM
Same Problem.

It makes me mad all the time  Angry

And It's not good at all for beginners who want to buy into ANC when there are problems with Buying and Withdrawing.

Same problem. Tried to withdraw from bleutrade 2 days ago and the transaction still havent gone trough. To fix this should be highest priority.

Quote from: niteglider on August 22, 2014, 11:31:12 PM
Quote from: TCB4728 on August 21, 2014, 06:32:52 PM
Anyone else with the following problems with ANC?  My multipool operator sent earned ANC to me on August 18 at 2:01AM CDT, was not received and posted to my wallet until August 21 at 13:58 CDT.  The multipool operator states:  "The transaction hasn't been included in a block yet.  It should make it into a block eventually and be confirmed.  I have no control over this.  It's been an ongoing issue with the ANC network for a few weeks now."  That would seem to be a very strong negative against this coin.




Yes, I am on the anonmining.com pool and it took a couple of days for an autotransfer to actually post to my wallet.

It was only 5 ANCs.

What gives?

In conclusion this is not a problem with cryptsy or "craptsy" as it is being called. It seems meeh and k1773R are aware and getting these transactions to confirm eventually so i see no reason to suspend the wallet as suggested above"

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
illodin
Hero Member
*****
Offline Offline

Activity: 966
Merit: 1003


View Profile
October 11, 2014, 02:50:44 PM
 #3311

I tried to browse through this thread but it's just huge so sorry if I missed it if this has been discussed already - has there been (and if so, what kind of) improvements made to the original zerocoin wrt scaling/performance, fixed denominations (no change transactions), or hiding tx amounts?
AnonCoinTwitter
Full Member
***
Offline Offline

Activity: 158
Merit: 100


View Profile
October 11, 2014, 03:24:12 PM
 #3312

Just days away from Zerocoin beta testing on Oct 15th! All code will be open sourced @github before public launch on Nov 1st

https://twitter.com/AnoncoinTeam/status/520955264145444864

Imminent hard fork will address the mining difficulty problems discussed above

https://pay.reddit.com/r/Anoncoin/comments/2ix6ny/a_hard_fork_is_imminent_pay_attention_to_forum/

matthewh3
Legendary
*
Offline Offline

Activity: 1372
Merit: 1003



View Profile WWW
October 11, 2014, 03:25:41 PM
 #3313

I tried to browse through this thread but it's just huge so sorry if I missed it if this has been discussed already - has there been (and if so, what kind of) improvements made to the original zerocoin wrt scaling/performance, fixed denominations (no change transactions), or hiding tx amounts?

Check the official wiki

K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
October 11, 2014, 05:56:14 PM
 #3314

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
I posted that they shouldnt change fee settings and/or also shouldnt patch the client o allow such huge txs (txs are limited to 100KB normaly).
Nothing from our side to be done  as there is nothing to fix. If someone dosnt want to play according to the rules, they shouldnt wonder why things break. Thats the beauty of a decentralized system.

[GPG Public Key]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
varun555
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
October 11, 2014, 05:57:56 PM
 #3315

How come the ANC/BTC exchange rate in anoncoin mining pool is showing as 0.00000434 HuhHuh?

EDIT: It's back to normal ! (Phew!!!!)
Simcom
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


View Profile
October 11, 2014, 10:16:26 PM
 #3316

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
I posted that they shouldnt change fee settings and/or also shouldnt patch the client o allow such huge txs (txs are limited to 100KB normaly).
Nothing from our side to be done  as there is nothing to fix. If someone dosnt want to play according to the rules, they shouldnt wonder why things break. Thats the beauty of a decentralized system.

I guess what I don't understand is: Cryptsy claims they are compiling directly from source, so why is the wallet creating transactions above 100KB by default? 
gunzeon
Member
**
Offline Offline

Activity: 73
Merit: 10


There's a new king in the streets


View Profile
October 11, 2014, 10:33:17 PM
 #3317

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
I posted that they shouldnt change fee settings and/or also shouldnt patch the client o allow such huge txs (txs are limited to 100KB normaly).
Nothing from our side to be done  as there is nothing to fix. If someone dosnt want to play according to the rules, they shouldnt wonder why things break. Thats the beauty of a decentralized system.

I guess what I don't understand is: Cryptsy claims they are compiling directly from source, so why is the wallet creating transactions above 100KB by default?  

I imagine that their house wallet contains squillions of sub 1 ANC coins; to make  my withdrawal they needed 400 inputs - all nickel and dime amounts and the size.

EDIT: not exactly sub 1 ANC but relatively small when compared to what is a reasonably sized parcel of ANC to trade

This was it here: http://ancblockchain.com/tx/f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6

./anoncoin/src/anoncoind getrawtransaction f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6 | wc
      1       1  143393
( ie: 143kB )

BTC: 1gunzeo8X7iYznsnmgveUQDuRj6vhzyK6 ~~~
Simcom
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


View Profile
October 11, 2014, 10:52:59 PM
 #3318

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
I posted that they shouldnt change fee settings and/or also shouldnt patch the client o allow such huge txs (txs are limited to 100KB normaly).
Nothing from our side to be done  as there is nothing to fix. If someone dosnt want to play according to the rules, they shouldnt wonder why things break. Thats the beauty of a decentralized system.

I guess what I don't understand is: Cryptsy claims they are compiling directly from source, so why is the wallet creating transactions above 100KB by default?  

I imagine that their house wallet contains squillions of sub 1 ANC coins; to make  my withdrawal they needed 400 inputs - all nickel and dime amounts and the size.

EDIT: not exactly sub 1 ANC but relatively small when compared to what is a reasonably sized parcel of ANC to trade

This was it here: http://ancblockchain.com/tx/f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6

./anoncoin/src/anoncoind getrawtransaction f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6 | wc
      1       1  143393
( ie: 143kB )


That's my understanding, but shouldn't the wallet be able to handle this by adding a larger mining fee so that the txn gets confirmed?
K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
October 12, 2014, 12:00:12 AM
 #3319

This was a good review of the problem - thanks for compiling this.  Looks like if the transaction size is too big it will fail to confirm regardless of the the fee included. Can we get a dev response?  Are you guys trying to identify this bug?  The doesn't seem like it should be a very difficult thing to fix, probably just a couple lines of code.
I posted that they shouldnt change fee settings and/or also shouldnt patch the client o allow such huge txs (txs are limited to 100KB normaly).
Nothing from our side to be done  as there is nothing to fix. If someone dosnt want to play according to the rules, they shouldnt wonder why things break. Thats the beauty of a decentralized system.

I guess what I don't understand is: Cryptsy claims they are compiling directly from source, so why is the wallet creating transactions above 100KB by default?  

I imagine that their house wallet contains squillions of sub 1 ANC coins; to make  my withdrawal they needed 400 inputs - all nickel and dime amounts and the size.

EDIT: not exactly sub 1 ANC but relatively small when compared to what is a reasonably sized parcel of ANC to trade

This was it here: http://ancblockchain.com/tx/f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6

./anoncoin/src/anoncoind getrawtransaction f615e8772e65dcf1da14154a9926df7e07f30b534745ce980760ff0b3a17aee6 | wc
      1       1  143393
( ie: 143kB )


That's my understanding, but shouldn't the wallet be able to handle this by adding a larger mining fee so that the txn gets confirmed?
The default wallet dosnt create transaction bigger than 100KB, https://github.com/Anoncoin/anoncoin/blob/master/src/main.h#L33
Everything above is non-standard and not mined with default settings/codebase.

[GPG Public Key]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Simcom
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


View Profile
October 12, 2014, 12:49:37 AM
 #3320

That's my understanding, but shouldn't the wallet be able to handle this by adding a larger mining fee so that the txn gets confirmed?
The default wallet dosnt create transaction bigger than 100KB, https://github.com/Anoncoin/anoncoin/blob/master/src/main.h#L33
Everything above is non-standard and not mined with default settings/codebase.

So if I tried to create a transaction above 100KB would the client throw an error message? Are you absolutely positive that it would be impossible to create a txn above 100KB with this code?  Have we tested it?  I just find it hard to believe the cryptsy rep would come in here and lie about using our source code to create invalid transactions.
Pages: « 1 ... 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 [166] 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 ... 265 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!