I posted this on reddit, but figured I would cross-post here. I think I understand the concept here, basically a large pool can flood the network with transactions to boost the average txn fee paid by legit users. They can potentially make more than they spend because they get back the fees on the spam transactions they create.
What I don't get is why the large spamming pool has an advantage over a small non-spamming pool in this scenario? The non-spamming pool pays nothing and gets to collect profit on both the spam transactions from the big pool and the normal txn fees from legit users, while the big pool only gets to record a profit on the legit txns, plus they have to pay out the spam txn fees to other miners for any blocks they don't solve. Anyone care to clarify where I am going wrong here?
|
|
|
I am going to be installing armory on Ubuntu 14.04 - is it safe to use the instructions in this video? http://youtu.be/w9TGkUgekLYCan someone take a look at it and tell me if everything is legit?
|
|
|
In what year does your regression intersect with $1M USD?
|
|
|
I have some news: the testnet will be delayed by 7 days. This is necessary because the code is not as close to being ready as I had anticipated when I made that estimate. I have come up with a schedule for remaining components to finish. I will give updates at ~8:00 UTC each day with what parts of the schedule I have finished the previous day (I am at a UTC-7 timezone). Whenever possible, I will also provide evidence that the functionality works. Here's the schedule: 10-14 | 10-15 | 10-16 | 10-17 | 10-18 | 10-19 | 10-20 | 10-21 | CWalletCoin | accum. chkpts in block wallet witness update wallet mint logic
| refactor CoinSpend RPC create spend + impl. store own spend pieces locally RPC get seeding spend proofs | net: seed spends net: receive and verify spends store received spend pieces | wallet spend logic | debugging (GUI if time permits) | debugging | debugging |
I know that one week may seem like forever to some of you who have been eagerly watching this thread and IRC, but this is only a 15% increase in the time required since I started working full time on this, so not an unusual delay compared to similar large software projects. The new launch date and time will be 2014-10-22 at 16:00 UTC. Thanks for the update, we appreciate your hard work! A little delay is ok with me if it means we get a quality product - I like the idea of the daily updates!
|
|
|
It would honestly make no sense if my coins after a withdrawal are gone due to a faulty. I would get furious. Im waiting patiently but my patience is running low.
Your coins are 100% safe. Bittrex should have made this clear to you. Essentially your transaction is "stuck" because bittrex created a transaction larger than 100KB. Our deamon has some sort of bug that allows this sort of transaction to occur and we are trying to figure out where the bug is so we can fix it. Please do not worry because your coins ARE STILL IN THE BITTREX WALLET, bittrex just needs to combine some inputs and re-send your coins.
|
|
|
So due to volume I wanted to transfer my Anoncoins from Bittrex back to Cryptsy. Now it seems Bittrex has "confirmed" my withdrawal, but nothing is showing up on the blockchain. It has been 2 hours since I requested my withdrawal.
As I read above (stupidly I read more of this thread after my withdrawal) it seems that bigger transactions are struggling to get through I lack knowledge when it comes to techs & specifications. Is this problem solved/being solved?
Sorry for bothering ;-)
Thanks in advance,
Clyze
Hi guys, referring back to this post; It has been quite a while since I requested my withdrawal from Bittrex to Cryptsy. Here is some more information regarding my withdrawal. Withdrawal History Hide cancelled withdrawals Search: DATE CURRENCY UNITS STATUS 10/13/2014 12:37:03 PM ANC 969.26520089 Completed Address: AYUpQqCftJbQEqpuvw4RrQKz19gFtC2VFC TxId: 838e3b333ac6a64e5eed95c320bdee2ff2121dac170a634fbe498f739d2257c9 It does not show up on the blockchain and I am quite sure we're at a new block at the moment. Time passes by and I am getting more concerned. As I am incredibly clueless on this whole situation. The last information I could provide is the address of my Bittrex account; AWQNFCwMBomJWxNLT2RrXnvtVbt1tL4yQU If you search that addy on the blockchain it still shows the funds before my withdrawal. I hope someone can clarify things for me. Is there a reason to be concerned? Thanks in advance, Clyze No you should not be concerned - the fact that the transaction has not hit the blockchain yet suggests this is a problem on bittrex's end. Open a support ticket with bittrex and they will take care of it for you.
|
|
|
I'd like to correct a couple of misunderstandings regarding Darkcoin in your otherwise outstanding PR material. First, you say that DarkSend is a mixing service. It's not a service, it's a decentralized offchain mixing implementation. Secondly, you say that with blockchain analysis software, it is easy to deanonymize transactions that have been mixed using these services (which include DarkSend). But because DarkSend mixing is done offchain, it actually cannot be deanonymized by analyzing the blockchain. Whereas with enough computing power (quantum computers, or unexpected advances in math), onchain anonymized blockchains (zerocoin, cryptonote, zerocash) can be deanonymized. In that sense DarkSend is future proof. Hi, I'm not trying to start any flamewar here or disparage DRK in any way (I am a prominent member of the darkcoin community after all). But I need to respond to this post in the interest of defending the facts. It is absolutely 100% incorrect to say that Darksend mixing occurs offchain. It happens 100% onchain and I have spent many hours analyzing the Darksend transactions on the blockchain during DRKs early development and communicating with Evan about how to improve the process. I think DRK does a good job of anonymizing transactions, but they are still onchain and they could potentially be de-anonymized via taint analysis under certain circumstances - read Kristov's analysis for further details. DRK is an excellent coin IMO, but your statement above is inaccurate. The best way to describe DRKs mixing is "a decentralized multi-step mixing service".
|
|
|
I've been hearing comments on here about mining problems. I am thinking of moving my Anon Coins from Cryptsy to Bittrex, am I risking not having my coins transfer properly? Thanks in advance.
I have moved from and to cryptsy many times over the past few weeks and have had zero problems. The mining issue is just that we get stuck at high difficulty sometimes for a few hours because our diff. algo needs to be updated, the coins will arrive at their destination regardless.
|
|
|
lol how much are they paying you? Your 3rd trolling account in as many weeks. someone is desperately trying to shake out weak hands.
|
|
|
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.
|
|
|
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?
|
|
|
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?
|
|
|
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.
|
|
|
Awesome. Looks like they are fixing the diff. algo before ZC implementation. Smart move.
|
|
|
xpool.net is now operating on donations. Zero Fees! I get webpage not found when I click the anoncoin link
|
|
|
|