 Show Posts
|
|
Pages: [1] 2 »
|
Also, the approach used here to link IP and TX is complete nonsense in my opinion.
Even if you are connected to all nodes out there, it is still possible to receive a transaction from an IP first even though someone else is the originator.
1. Imagine there is a small node with a bad internet connection sending a transaction. He has a list of nodes he is connected to and has to broadcast to all of them.
2. User X (having a huge internet connection) is the first one to broadcast and Eavesdropper Z is the last one in the peer list getting his broadcast at the very end.
3. Due to the slow internet connection the time between broadcasting to User X and broadcasting to Eavesdropper Z is sufficiently large.
4. User X relays the TX immediately after receving the TX from the originating node to all of his peers ... including the Eavesdropper Z which is also connected to him.
Now the problem kicks in. Eavesdropper receives the TX from User X before receiving it from the slowly connected originator, and therefore thinks the connection was actually created by X.
How the heck such approach could ever be decided to be implemented?
E.K. totally agree - but it is still quite useful for statistically monitoring traffic btw countries. /M |
|
|
|
How do you determine which entity a transaction orginates from in the bitcoin network and relay that information to someone without given that somebody the IP associated with said tx?
Clustering of addresses from the blockchain - like walletexplorer. Wallet explorer keeps a list of entity <-> wallet mappings, you can build such a list from anyone you transact with, and it is only the financial institutions / big wallet services that are relevant here for compliance purposes. Would it perhaps be possible for a financial company, ie. an exchange, to subscribe to your services, and then just get automated recommendations based on tx'id. So that exchange could then plug into your service, and if a customer sent funds to the exchange, and you service returns a "no good" to the exchange, the customer is denied service at the exchange? That would basically put you in the same category as a rating bureau, giving you voting power over which customers should be given service at an exchange or similar. But there could be many false-positives, and the data might not be accurate for its purposes. And if enough institutions use you service, then govt. entities could force you into blacklisting certain entities, just like the USG did with Mastercard and VISA when they put a wrench in the funding for Wikileaks, or how they pressurized VISA and Paypal to stop processing payments for Mega. In essence you could contribute to breaking bitcoin fungibilty. Worse, customers that are rejected at a service based on data from your analysis service might not even get to know why they're rejected by their service provider.
Before answering I think it is important to stress my view on bitcoin: I believe that bitcoin is a great technology enabling online cash hereby including possible the entire 3rd world into our economy, it should hence be regulated and integrated into the existing financial system. - I do sympathize with some libertarian views, but I am Danish, I don't believe in revolutions - I believe in the little change every day, and I truly believe we get a little bit better world if you can buy and sell bitcoin in your normal bank. Lets split your question above in the 3 important parts it contains: 1. Do financial services need to do customer due diligence in bitcoin land - and can they use Chainalysis for that ? Yes, they do need to check their customers - the alternative is that they don't and take the entire risk them selves causing them to do time at some point by indirectly contributing to Money Laundering. Please don't ask and expect from financial services that promote bitcoin that they should take that risk. 2. Could you hereby risk becoming a persona non grata even if you did nothing wrong ? In bitcoin there is no persona non grata - bitcoin is cash - further, there is no tainted money, they are fungible - but again as in cash - there sure is stories that you as a financial service inst need to react upon. Lets say you want to deposit $1m in cash in your bank - will the bank let you do so - most likely no, at least not w/o having a good idea that the funds are obtained in an ok way (that is their legal obligation). So, say you are the head of Red Cross and you just had a huge collection and you again show up with the $1m. Then yes the bank would accept them. The money are fungible, it is all about the story befind / the origin of the funds. Another example could be the cryptolocker guy trying to turn the BTCs obtained through his virus into USD - of course it is ok for an exchange to screen for that, of course it is also OK to screen for other addresses that the exchange thinks contain other stolen funds. If you don't like that, you are basically expecting the exchange to take a huge extra risk. 3. Could govt force exclusion of certain players this way ? We choose Switzerland as a country to incorporate in mainly for this reason. I guess govt can always enforce a lot of things, that kind of goes with govt. Are we by what we do building weapons for govt ? Or is bitcoin core building tools for money laundering, slavery etc ? Both arguments are in my book equally right or wrong (Personally, I think they are both wrong). We have innocent customers today having their traditional fiat transfers being interrupted, sometimes only because there's a false-positive match on a "list" that banks keep to attempt to prevent funding to terrorist groups etc. Do we really want the same for bitcoin? I'm of course not advocating that terrorist groups should be funded with USD, EUR, BTC or anything else, but on that note, perhaps stopping the "bugsplatter" in remote countries by remote controlled drones would be an idea.. I don'ẗ know what creates more terrorists, having innocent families killed (read: Drones and the rise of the high-tech assassins) in Afghanistan, or allowing people to freely use bitcoins.. I actually think that the measures against money laundry, terrorist financing etc are pretty reasonable as they are today, some parts are a bit too much, some are perhaps a bit too loose. As I stressed earlier, any customer is a possible liability for a financial institution, if they onboard the wrong ones they can end up pay fines or do time. Of course they are cautious, and yes it will result in false positives. Already today I think it would be awfully hard for someone from North Korea or Afghanistan to open an account on any bitcoin exchange. A pity if he or she was actually trying to promote a better world there, but the risk is to big and that causes casualties. Bitcoin is meant to be a alternative to the status quo. In that regard, you're not contributing, despite your excuses.
Bitcoin is a technology - it is cash on the internet, and as such an alternative to a lot of things. It might end up being also an alternative to banking as we know it and even to government, but I believe that through coexistence bitcoin will succeed most as a technology. You have stated that the nodes of yours were running to collect, analyze and prepare data for a blog post. That might be so, but as you also have a public website, see the quote above were your intentions are quite different.
My comment (no 1 from my first post) was re the legal accusations - anyone are free to believe what they want - we had no bad intend, which at the end of the day will be important when it comes to legal. You're also trying to play down what you're doing by pointing to what google does, that somebody would do it anyway, what blockchain.info does etc, still you did shut down the nodes in question when attention was brought to this issue.
We shut down the nodes as we learned they interfered with breadwallet. And right now we are having an important discussion on what you (ethically) can and cannot do on the bitcoin-network and how you should do it. It would be arrogant to just keep them running now, even if patched for breadwallet. I'm sure however on a financial level that providing such a "regulatory compliance"-service is not a bad idea, but for many involved in bitcoin, money is not their primary motivator. If you believe in bitcoin, and want to help the community, perhaps now would be a good time to shut down the Chainalysis-enterprise, and work with the core devs to prevent others from doing the same as you've been doing lately, perhaps even by showing some of them your code and tools to help speed up development for protecting the fungibility of bitcoins.
I don't see fungibility of bitcoin threatened - and I am strongly opposed to the creation of white/black/red/[choose color]-lists of bitcoins per se, it doesn't even make ses from a compliance viewpoint. Also, no one has a mandate to say what bitcoin is about from a political pov. Bitcoin is a technology enabling cash transaction on the internet - pretty d*mn cool. How it is used politically will always be segmented. On a non-similar note, but to demonstrate an ethical point. A clever programmer could work on software used in a millitary weapons system, a system that was largely sold to third-world countries, and left lots of deaths in its trail. The programmer could shrug his shoulders and say: "I'm putting food on the table of my family, the fact that 100 families dies in Africa because of my code, is frankly none of my business, if I did not write it, somebody else would". Perhaps somebody else would do it, that does not mean that this particular programmer had to do it.
Of course there's no direct similarity to block chain analysis and millitary weapons systems, but the ethical points are the same. Every person matters, and the action of every single person combined becomes the actions of the whole population.
Of course it's possible to separate yourself from the collective whole, like many do, and only think about their own financial gains. In the end, I'm not sure if that's what brings the greatest satisfaction.
In summary, I'm not intending to bring on hate, just to convey my view on the matters. Solution to this issue must be built on a technical level, not on a human level.
I did already comment on the technology ethics side - there are casualties also just by doing bitcoin core dev. If you knew me personally you would know that I am against mass surveillance too - the last 15 years of terror attacks have shown that intelligence agencies don't lack data, they lack the ability to understand them (j'suis Charlie, Copenhagen, 9-11 etc - all done by people known by the intelligence agencies, so not a lack of data, they need to use better what they have - and not to start collecting data on the rest of us instead). But proper customer due diligence is not surveillance, neither is statistical overview of pr country bitcoin transfers. Final note - I agree that if you have a wish for using bitcoin in a super private / anonymous way it is a technological solution/skills you need, not policies. Sometimes you might want to stay anonymous, sometime you don't - for sending anonymous transactions - use Tor, and, I would also recommend you to not post a bitcoin donate address on your site, that is unless you regenerate a new pr session. (it is of little value to anonymize your transaction if the sending address can be linked to a site you control, just by googling it). Cheers, Michael |
|
|
|
|
Hi again,
Got some PM requests for clarifying legal issues etc. Your guess is as good as mine, but I think it is important to stress a few facts first:
1. Me explaining to coindesk/insidesbitcoins what Chainalysis do in general (Compliance, Investigations etc) has nothing to do with the nodes - we are not using transaction to IP mapping for anything but statistical research - aka the blog post already mentioned. This fact is, as I see it, highly relevant if we start to discuss any possible legal issues.
2. Claiming that Chainalysis should do anything illegal based on other nodes connecting to our nodes relaying INVs is highly speculative. I cannot see any difference btw that and connecting to any other service (HTTP/DNS etc) and recording that info for statistical purposes. Further, take e.g. blockchain.info where any first posted INVs are recorded and shared with all future users. How is our statistical analysis different from that ? And note even here that Chainalysis are not and have not any intention to share privacy sensitive info (IP numbers).
3. General legal considerations - I am by no means an expert on this - but this is a relevant discussion - when are you (illegally) eavesdropping by participating in a p2p network ? What are you allowed to do with the data/metadata (e.g. INVs and TXs) you receive ? What can you as a p2p user (legally) expect them to be used for ? Do we actually expect any regulation to cover here at all ?
Cheers,
Michael
|
|
|
|
|
Hi all,
Chainalysis here - sorry to have caused any worry or confusion. We were preparing data for a blogpost on bitcoin traffic by volume btw different counties. We chose specifically to setup a number of nodes on the same /24 net to avoid any bitcoind or other vital parts of the network to be caught only on our nodes as we initially havn't build the transaction forwarding into the probes.
As we learned some SPV nodes were affected we have now shut down the nodes.
Sending a bitcoin transaction in a p2p network will always to some extend reveal your IP, like your IP is known by google as soon as you google something or by your preferred DNS server looking up domain names. We implicitly trust these services and that they do not reveal our behaviour on the internet. We also know that e.g. google of course profit from collecting this information which we accept to the extend that they don't sell specific information, but only statistical information compiled from their measurements.
We still think that there is a lot of interesting info you can learn from the bitcoin network by doing this kind of experiments, however, we also accept a do-not-trace wish from users. So perhaps the right way for network analysis research going forward is to:
1. Ensure probes comply 100% with the protocol (shame on us)
2. Add a link (url) to the specific purpose in the version name
3. Keep a tag in the version name [probe / recording / whatever] so nodes can choose to friendly opt out
But also note that the above measures and current protocol does not protect you against a real spy net at all, Tor is still the best solution for this purpose.
Sincerely,
Michael
|
|
|
|
not sure if i totally understand the implications, but does the fact that anyone can update the values means that the ownership of the domain is compromised? i would guess it's not, in the sense that once they fix the bug then the real owners of the domains can just update again to the right value (in case someone else updated their value without authorization) and no one else can change it once it's patched.
i think it's not a big deal for the owner of the domain to have to do an update after the patch rather than having to cancel all the domain registrations
Yes, the ownership of the domains is compromised - in fact they are equally owned by everyone, so if you have a domain you can steal/grab/claim any other domain at will. Well, the update I executed means that I now own the d/bitcoin domain - and tracking back trying to fix this stuff could be quite complicated. Also, namecoin is a math based currency - the math is fine, however, someone forgot to check it before trusting in it. So today namecoin is nothing but an alt coin - it is not a secure registry for key-value pairs, but it could become one in the future, once the rules are switched on. To claim domains backwards becomes inelegant, messy and calls for an authority which we are usually not in favor of... |
|
|
|
So all the brains and noise in crypto and open source projects over looked such a disaster?
I'm not sure whether to congratulate you or offer my condolences to the dev team and the big players.
This is rather interesting, not only for crypto, but also for all open source projects; having a project "open source" and calling the myth of "open source is more secure" doesn't make the code more secure.. Having developers like yourself actually looking into the code and testing the hell out of every possibility is what makes it secure.
Nice work, hope a fix, patch, rebirth or whatever you want to call it will be pushed out soon as such noise is in no way good to any cryptos including but not limited to Bitcoin
Open source is more secure exactly because it can get wider peer review. Programmers make mistakes, but with closed source issues can go un-notices for years - even on purpose while other exploit the 0day. The NSA have been doing this for example. Exactly, I'm not saying it isn't, I'm trying to say that if a software is open source, it shouldn't be taken for granted. I'm not a dev myself, I wish I were, but I think devs in the crypto community should make some sort of organization to do nothing but test for such bugs and us the users can donate to them, or they should be paid from TX fees, ads etc... This community is getting wider and bigger, being decentralized doesn't mean we can't have a well known organization to look after the technical side of things for all crypto related software Well, I disagree, I see it as the duty of the exchanges and wallet services to perform this kind of scrutiny / review before adding a new alt-coin to their assets. I know that this has not been the practice so far, while everything has been wild west gold digger mentality, but things are getting legit, and you should do your best to secure your customers values. Anyway, it was actually in this process I found the above bugs, and I have seen other bugs in other alt-currencies, but never any alarming ones until now. |
|
|
|
Looks like NMC is dead. Gox will never add it after this.
Ironically, it was while adding it to Kraken, that I discovered this - how could we possibly, as an exchange sit with this knowledge and start trading NMC? Now, it is different, and we might take it up again, but we need to fix the namecoin key-value database integrity first, or at least see it being fixed soon. |
|
|
|
It's just a hardfork that needs to be done in order to enforce the rules, no?
Well, it will be awfully hard to administer such a hardfork - either you reorganize all the way back to block 139872, from when you have the patch ready, or you need to backtrack false takeovers and reverse them. I'd say that it is more fair to cancel all reservations, after all, they never really were enforced anyway... Further, it would be healthy to clean up the list of domains. |
|
|
|
How they going to fix this?
I suggest: "or just a cancel of all the name reservations starting from some future block" - so enforce a reset of all name reservations, say from block 141000, and following that enforce the rules. This means that all domains reserved are worthless, but that is also the case today due to the bug. However, this approach might cap the NMC rate decline. |
|
|
|
This is the postmortems and obituary over namecoin. In fact it never really existed, but by block: 139872 it became clear. However, if you haven' t noticed yet read on... Edit 131016 : A nice fix is currently being tested, so it seems like namecoin will be back in business. Cudos to the "snailbrain" and "phelix" for cooking it together and acting fast. So current status is - don't buy a domain from someone, and don't trust any important key-value pair in namecoin before the fix has been rolled out! - Will update once it is there, but could take days to deploy at miners.Namecoin has always been my favorite alt-coin - it had a clear purpose, different from Bitcoin, offering a nice way to keep a de-central registry of key-value pairs. About a month ago I had a closer look at namecoin, to integrate it into libcoin on the Kraken exchange. Libcoin is a complete other story, it is a library supporting bitcoin as well as several of the alt coins, enabling easy construction of anything from light weight wallets to full server wallet solutions for exchanges and merchant sites. However, back to namecoin... I have integrated several alt coins, and I know the machinery pretty well by now. The engine of any bitcoin based crypto currency is the ConnectBlock / ConnectInputs methods in main.cpp. They keep the rules of when to accept a block and when to reject a block, and it is there you make patches to enable anything from alternative hashing algorithms (litecoin) to merged mining (namecoin and others) as well as add new features and rules. Namecoin keep a reasonable separation through the definitions of hooks, implementing the actual rules in a separate file, namecoin.cpp. So the real interesting stuff in namecoin is happening in namecoin.cpp in the ConnectInputs method. This one is called from ConnectInputs in main.cpp and hence have the ability to change and add rules. All namecoin rules are kept hidden from the bitcoin script rule engine through OP_DROP opcodes, i.e. some special opcodes and data is entered, followed by a matching chain of OP_DROP commands, so the normal script rule engine will simply ignore anything namecoin'ish. The special op codes of namecoin are: OP_NAME_NEW
OP_NAME_FIRSTUPDATE
OP_NAME_UPDATE The reason for the OP_NAME_NEW/OP_NAME_FIRSTUPDATE setup is to avoid domain opportunists listening for new domain reservations and issuing competing reservations to later sell the domain back. So first you issue a: OP_NAME_NEW << hash << OP_2DROP Where the hash is composed of a random number and the domain, hashed. You are not allowed to issue a first-update, finally registering the domain, before after 12 blocks, ensuring no block reorganizations can enable a domain opportunists to steal your domain. In the name_new/name_firstupdate RPC calls this rule is nicely enforced, however, when you look in the ConnectInputs method you find rules enforcing a fee, rules enforcing the 12 blocks, but NO RULES ENFORCING THE HASH! [namecoin.cpp line 1874-1907] ]. So any name_new can be used as input for ANY name. This means that the domain reservation is not enforced at all leaving namecoin completely open for domain opportunists. Clearly the patient is bleeding and in urgent need for help, but brace yourselves, this is not affecting already registered domains so it is fixable by a proper patch, and a recommendation to not reserve any new domains before the patch is in effect. Relieved that there was a cure I continued with the standard examination, to check if the rest was ok. The key lines in namecoin.cpp are probably 1930 to 1949, this is the very core of namecoin. This is the enforcing of a name_update - a name update is the script: OP_NAME_UPDATE << vchName << vchValue << OP_2DROP << OP_DROP So, take an already registered name and update that with a new value. Now you would expect some code enforcing that only an input of that name can be update to another value - but NO! Again there is no enforcing of the core ruleset. So you can in fact update the value of any name in namecoin by any other input name. And after that you own it, or well, as much as you can actually own a name who anyone can update. The final test was to try it out - (sorry) - I might had overlooked something, so, I changed the name_update algorithm to enable such takeovers, and did a: ./namecoind name_fakeupdate d/postmortem d/bitcoin "Namecoin died October the 15th 2013, coinslayer" Try name_history on d/bitcoin and see for yourselves - there is no enforced integrity of the key value pairs in namecoin. So namecoin looses its entire purpose. The problem is that there is no fix to this - it is similar to being able to randomly take ownership of other peoples money, all the value is gone. I tried, initially, a silent fix contacting namecoin developers and key users more than a month ago, but I never got any answers back. Perhaps, the best future for namecoin now is a rebirth with a new genesis, or just a cancel of all the name reservations starting from some future block ? I should also note that up until block 139872, no one have exploited the bugs. The libcoin code actually enforced the above rules, and I was able to download and verify the entire chain, now I have added a flag, ignore_rules, to get pass block 139872. Coinslayer aka Michael, Chief Operation Officer, Payward Inc. kraken.com |
|
|
|
|
r38XVgX5e4GazRRFB8brYzjtRtt3uQkGrq
Thanks!
|
|
|
|
|
Ups - sorry about the errors - I have just upgraded the server backend software, and I have not been through a rigid testing of everything following that - thanks for reporting.
As for the ceptacle.com/cash - I have kept that on on invitation only until I got things cleared with the creditcards - so that is why...
The wallet is in the localstore of the browser (similar to blockchain.info) this way it is locked to a spicific domain (microbits.com) and hence it cannot be tampered with by an evil mercant. Microbits does not use payment links, but a payment protocol, similar to the one currently being implemented for bitcoin. This means that you send the signed transaction to the merchant leaving it to him to broadcast it. Hence a merchant can use a single btc address and not worry about having a wallet online on his webserver.
Do you have a specific use for such setup right away ?
|
|
|
|
Yes, such thing does exist  https://microbits.com - you can test it out trough the demo news paper ceptacle.com/post and ask me questions if you find some issues. I created microbits.com last year, and have had some issues in finding a) the right exchange rate policy and b) a reasonable way to inject bitcoins into the system - I have a credit card setup running, but credit card -> bitcoins are a bit of a challenge. Any particular project you have in mind for your request ? Sincerely, Michael |
|
|
|
The amount of "dust" in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.00000001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!) This means that a huge part of the block chain is used for essentially nothing - e.g. the sum of the 11% is worth roughly 2 US cents ! The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing wrong with that, however, we should work on ensuring that too many too small payments will not kill the size of the blockchain in the end - further, they are essentially too small to be included in other transaction as the added fee will often make it more expensive to remove them. Hence, there is no incentive to get rid of them. I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see: http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging: 1-99 Satoshi: lives for 210 blocks 100-9999 Satoshi: lives for 2100 blocks 10000-999999 Satoshi: lives for 21000 blocks 1000000-99999999 Satoshi: lives for 210000 blocks Only amounts above 1BTC lives forever - (or we could even impose aging on those too..) The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever. This scheme will impose some lifetimes also on e.g. colored coins (hence you need to use a certain amount to borrow space on the blockchain for the time needed, or simply transact them). If you like this I would be happy to write it into a BIP. Thoughts ? |
|
|
|
If you want to try out microbits and ceptacle/cash please send me a mail. The cash service is *giving* out real money, until I get it approved at the payment provider, so that is why it s restricted. Sorry about the .zip file - I got a bit side tracked creating it, but I can guide you through if you like. Also have a look at the microbits presentation from BitCoin 2012: http://ceptacle.com/presentations/microbits.pdfCheers, Michael |
|
|
|
Jeg kommer også - har en præsentation |
|
|
|
I just stumbled over this article: http://www.forbes.com/sites/janetnovack/2012/03/26/24-states-moving-towards-decision-on-taxing-groupon-livingsocial-deals/The discussion is, as I see it, also relevant for for bitcoins. Digital currencies like bitcoin are, for a very near analogy to a gift card or a group on voucher. You buy your proof of value and then later you use it in a store that accepts it. The decision by New York and other states to charge tax on the value and not the gift card value is actually accepting a gift card as a for of currency or a proof of depth. I expect bitcoins to be treated similarly resulting in nor sales tax on bitcoins. We have had a similar discussion in the Nordic/EU forum, but I think the article from forbes indicates that it is a relevant discussion for US too. Cheers, Michael |
|
|
|
Debugging code is both tedious and contagious. You are held in suspense between your curiosity, stubbornness and immense boredom. It is one of these needle in a haystack tasks that can last for days and during the endeavor you feel awfully unproductive. However, there are often some lessons to be learnt, and sharing debugging stories is for code gurus like sharing fishing stories for fishermen. A famous story is the one from Fortran that caused a satellite to crash (Mariner Venus) due to '-' for '~' error... This story is in C++ and about a missing '&', and like the satellite story it also begins with a crash. I have had my customized bitcoin server (based on libcoin) running on different mac and windows desktop machines running for weeks with no issues, it survived reorganizations and the recent date based protocol changes (BIP0016/BIP0030) silently, and seemed pretty stable. I hence installed it in its production environment a Ubuntu machine at Linode. It had compiled and functioned several times before on linux, except that sometimes running on small virtualized machines I had seen crashes due to memory issues. Nothing to be really alarmed about, and the instance running on an amazon large instance had never crashed. I hence compiled to code and started it on Linode. Blockchain download... a reorganization and crash! Reason was bad_alloc, so most likely the memory issue, and afterall the Linode instance had only 1Gig of RAM. In my custom server I also keep some rather large data structures in memory, so I disabled these during chain download and tried again. Reorganize, and crash! Again due to bad_alloc. Annoyingly, following the crashes the databases got corrupted as well. I still believed that the crashes were due to low memory, but I wanted to make sure in the future that I could at least recover gracefully from database corruptions. So I tried to figure out what state the database was left in. In the reorganize method of the BlockChain class (basically similar to the reorganize method in bitcoin/bitcoin) there are a lot of nice tests to check if things fails - if blocks can't be read from disk or if disconnect fails. If this is the case the series of accumulated database transactions are aborted (TxnAbort) leaving the database in the same state as before, and ensuring that even thought the reorganization failed (and will fail again) the database is left in the same state and the same error will reappear on restart and can hence easily be debugged. In my case it was a memory exception thrown in the loop where all the txes are pushed on a stack to be resurrected after the chain reorganization. The exception is caught, but it is not caught before in the message processing method (ProcessMessage in bitcoin, handleMessage in libcoin). Here it results in an error message, but the program continues and the database transaction is never aborted (TxnAbort). The failed reorganize will repeat it self and the database transaction log fills up till 500 uncommitted transactions and then the BDB makes the program die. However, at some point in between, at least in my code, the best height was sat in the database and that caused the corruption. I fixed the issue by inserting a try catch around everything in reorganize up to the TxnAbort ensuring correct behavior even in case of a memory exception. Instead of rebuilding the database (from scratch download) I tried to rebuild the database: Forcing a reorganize 10 steps back and cleaning the blockchainindex for all non main chain blocks. However, that immediately caused another reorganize crash due to a bad_alloc ! This time the reason was clearly not a filed up memory. I debugged the code and the same loop as before was the culprit: // Queue memory transactions to resurrect
BOOST_FOREACH(const Transaction& tx, block.getTransactions())
if (!tx.isCoinBase()) {
vResurrect.push_back(tx);
}
The Block::getTransactions() was defined like: const TransactionList getTransactions() const { return _transactions; }
libcoin encapsulates all classes, and hence looping over a (const version) of transactions in a block is done this way. I have other part of the code (in Block) where: BOOST_FOREACH(const Transaction& tx, _transactions)
// do something with tx
is called multiple times with no problem, yet the code crashed there and it was tx that was corrupted! I changed the loop to a normal for loop using block.getNumTransactions() and block.getTransaction(int) - now the code ran perfectly up to block 171091 - which every bitcoinerd will recognize as the first block of March the 15th ! BIP0030... My BIP0030 code is: if (pindex->nTime > _chain.timeStamp(Chain::BIP0030))
BOOST_FOREACH(const Transaction& tx, block.getTransactions()) {
TxIndex txindexOld;
if (ReadTxIndex(tx.getHash(), txindexOld))
BOOST_FOREACH(const DiskTxPos &pos, txindexOld.getSpents())
if (pos.isNull())
return false;
}
Hey, again the BOOST_FOREACH loop! That construct was apparently somehow polluted - a google for 'BOOST_FOREACH const reference' gave this like: http://www.richelbilderbeek.nl/CppBOOST_FOREACHExample1.htmNote from Richel's page: //BAD: Compiles and crashes program
//std::clog << __func__ << '\n'; BOOST_FOREACH(const std::string& s, f()) { t+=s; }
So you cannot use a function returning a copy of a vector in BOOST_FOREACH, however a const reference to it works, but will spew a compiler warning. Changing Block::getTransactions() to : const TransactionList& getTransactions() const { return _transactions; }
// ^ note the single &
made everything work smoothly again. So the culprit was a missing '&' or more correctly that BOOST_FOREACH that didn't behave correctly. However, it does behave correctly when compiled on visual studio and Xcode. Hence I never saw that error before... What is the lesson learnt then ? I think there are two: * Use either exceptions OR false/true functions in a program not both! Somethimes it is better to crash than to keep trying. * Use macros (BOOST_FOREACH) with great care, the behavior is often hard to predict and also hard to debug. I will over time change all BOOST_FOREACH in libcoin to normal for / while loops. Thanks for reading this - I hope you found it useful! Cheers, Michael |
|
|
|
@TechnoMage: I just reread your earlier post, and if the gift card analogue does not hold, then your scheme of selling a brokering service will not stand either : Then it is Mt. Gox (or you as local reseller) that would have to add VAT on the product. But again, it is not bartering... @psy: gift card analogue again - at least in DK you are not obliged to "buy back" a gift card. Whether, on the moving price issue, we need to check this... An accountant friendly question could be if you may issue non price fixed value cards ? (like my earlier cheap Wednesday, expensive Saturday example) You could of course, in a shop setting, implement this as a coupon with different discount on different days, again some questioning to do  |
|
|
|
@BitcoinTraderIT: Agree, but this is in fact the gift card setup... You buy the right to buy a good from some organization (bit-pay), but which good and when you buy it has not yet been decided. It is decided at the time of delivery, which also is the time where the VAT should be payed - the rationale from the Danish tax authorities is that you don't know at the time of buying which product you end up using your gift card for, and hence you don't know which VAT rate that will apply (in DK the VAT for newspapers and personal transport is 0, 25% for the rest, in Sweden there is another rate for e.g. food). So - bottom line: it is NOT a barter... @psy: I don't think the fluktuating rate plays a role here. You could easily issue gift cards that would have a higher value on e.g. Wednesdays than on Saturdays (btw - could actually be smart... - need to check if it is actually OK...) the VAT would still be payed from the value of the actual good you buy. Just talked to our local accountant - VAT is for goods not for gift cards and other proof of value. Also note that a gift card in terms of accounting is listed as a debt - you owe the customer. Finally - gift cards can expire, there is even (in DK) a law that states how long they can last. In that case there is no VAT(!) as there is no goods. Anyway, the setup you propose - with guaranteed exchange rates, is one I am currently trying to setup |
|
|
|
|
