varun555
|
|
October 11, 2014, 09:39:28 AM |
|
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
|
|
October 11, 2014, 10:54:03 AM |
|
http://forum.bleutrade.com/index.php/topic,40.0.htmlPOSSIBLE 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
|
|
October 11, 2014, 11:14:33 AM |
|
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
|
|
October 11, 2014, 11:19:15 AM |
|
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
|
|
October 11, 2014, 12:44:51 PM |
|
http://forum.bleutrade.com/index.php/topic,40.0.htmlPOSSIBLE 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#msg8869037Quote 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
|
|
October 11, 2014, 01:07:49 PM |
|
xpool.net is now operating on donations. Zero Fees! I get webpage not found when I click the anoncoin link The link seems to be working now. Can anyone comment about the reliability of this pool?
|
|
|
|
tljenson
|
|
October 11, 2014, 02:05:12 PM |
|
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
|
|
October 11, 2014, 02:10:25 PM |
|
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
|
|
October 11, 2014, 02:38:03 PM |
|
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
|
|
October 11, 2014, 02:39:46 PM |
|
http://forum.bleutrade.com/index.php/topic,40.0.htmlPOSSIBLE 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#msg8869037Quote 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
|
|
October 11, 2014, 02:50:44 PM |
|
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?
|
|
|
|
|
matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
|
October 11, 2014, 03:25:41 PM |
|
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
Activity: 1792
Merit: 1008
/dev/null
|
|
October 11, 2014, 05:56:14 PM |
|
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: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
varun555
|
|
October 11, 2014, 05:57:56 PM |
|
How come the ANC/BTC exchange rate in anoncoin mining pool is showing as 0.00000434 ? EDIT: It's back to normal ! (Phew!!!!)
|
|
|
|
Simcom
|
|
October 11, 2014, 10:16:26 PM |
|
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
Activity: 73
Merit: 10
There's a new king in the streets
|
|
October 11, 2014, 10:33:17 PM |
|
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
|
|
October 11, 2014, 10:52:59 PM |
|
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
Activity: 1792
Merit: 1008
/dev/null
|
|
October 12, 2014, 12:00:12 AM |
|
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#L33Everything above is non-standard and not mined with default settings/codebase.
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
Simcom
|
|
October 12, 2014, 12:49:37 AM |
|
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#L33Everything 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.
|
|
|
|
|