Im getting compiling errors while it is trying to compile the connectivity_tool on ubuntu 14.04. Using Win7x64 for now until I can get some help to get it to compile.
What errors? /tmp/cc5ITsCl.ltrans25.ltrans.o: In function `handle_update_maintainers_info(boost::program_options::variables_map&)': cc5ITsCl.ltrans25.o:(.text+0x139f): undefined reference to `currency::get_blob_hash(std::string const&)' cc5ITsCl.ltrans25.o:(.text+0x13c0): undefined reference to `crypto::crypto_ops::generate_signature(crypto::hash const&, crypto::public_key const&, crypto::secret_key const&, crypto::signature&)' /tmp/cc5ITsCl.ltrans28.ltrans.o: In function `generate_and_print_keys()': cc5ITsCl.ltrans28.o:(.text+0x6c5): undefined reference to `crypto::crypto_ops::generate_keys(crypto::public_key&, crypto::secret_key&)' /tmp/cc5ITsCl.ltrans28.ltrans.o: In function `main': cc5ITsCl.ltrans28.o:(.text.startup+0x1a4): undefined reference to `command_line::arg_help' cc5ITsCl.ltrans28.o:(.text.startup+0x490): undefined reference to `command_line::arg_help' collect2: error: ld returned 1 exit status make[3]: *** [src/connectivity_tool] Error 1 make[3]: Leaving directory `/home/nirv/boolberry/build/release' make[2]: *** [src/CMakeFiles/connectivity_tool.dir/all] Error 2 make[2]: Leaving directory `/home/nirv/boolberry/build/release' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/nirv/boolberry/build/release' make: *** [build-release] Error 2 I can't reproduce it on my ubuntu, so can you give exact gcc version, os version and commands that you use for build? gcc version 4.9.0 20140405 (experimental) [trunk revision 209157] (Ubuntu 4.9-20140406-1ubuntu1) Ubuntu 14.04 LTS 3.14.1-031401-generic git clone https://github.com/cryptozoidberg/boolberry.gitcd boolberry; make -j When it failed I tried just make with the same errors. Downgrading to 4.8 fixed the issue. I didn't know it upgraded to 4.9. We had some issues with GCC 4.9/ArchLinux building too, we fix them in this commit https://github.com/monero-project/bitmonero/commit/9853ba8e0636ba6f1043bb4f52caff19fe54c8acYou can try merging that and seeing if it fixes it |
|
|
|
Yes I understand that "stuck" is a figure of speech to depict "crawling speeds", but people were complaining about txs that took hours.
We need to do a stress test on the network with 100-500-1000-10000 txs per hour to see if it scales and record the networks ability to process them. After the findings are recorded, an assessment must be done and a course of action should be decided on whether it needs fixing or not.
Doing a comparative test to other networks (like BCN and BBR) for similar amounts of transactions is also desired for comparison purposes.
The adaptive blocksizing works fine scaling to any blocksize up to the static limit of 5MB, propagation issues however will make the network difficult to use at these sizes. Because of the fast block timing, it's undesirable to instantaneously generate huge blocks, and adaptive block sizing assists in ensuring this does not happen. This is the same issue as seen with Bitcoin; there is no fundamental scaling issue CryptoNote coins have that Bitcoin-derived coins do not. This is exacerbated to some extent by larger tx sizes with CN coins, but a lot of this slowdown was simply due to pool related dust on the network bloating tx size, an issue that has been resolved. |
|
|
|
I knew CN has scaling issues, but this went beyond my expectation. I don't know whether the adaptive block size is at fault or something (I read the thread - but that's the extent of my knowledge regarding the root cause of the issues), but it was not "looking good" to have the chain "stuck".
The chain was never actually stuck, there's just a limit to how many tx may be included in a block at a time. Many users didn't understand this and panicked and kept trying to resubmit their tx to the network, only to find that the tx were already in the mempool waiting to be included in a block. Adaptive block sizing expanded the chain within an hour, and then the tx all went through. It seems there was a misconception with that userbase that because block timing is fast, that their tx should be as fast, however, this is not the case from the code or the original documentation. |
|
|
|
4) You left off a discussion of transaction identification by prefix. Comments? As a mechanism to keep the blockchain smaller, this seems like one of the most technically relevant ways in which BBR departs from XMR, given that the blockchain size is one of the big deals with the entire cryptonote family.
I was going over the features I readily disagree with. I'm not sure about the tx prefixing stuff, because I still don't entirely understand what it solves. It seems that he's making it so that you can't mixin outputs from before checkpoints as inputs, which means you're relying on centralized checkpointing dictated by him to establish what inputs are to be used. But, as you said, if this becomes useful, we can always implement it in Monero without a lot of hassle (the tx_prefix hashing is from the original ByteCoin code and used in signature generation). crypto_zoidberg knows the network code very well and is good at patching things relating to it, and the alerts system is a good idea and should be integrated into ByteCoin/Monero/etc. |
|
|
|
Consider the instance in which a user uploads their alias, and someone sends them a small output, maybe 0.1 BBR.
Now, the person watches the blockchain for when this output is spent. If the user with the alias spends it in a tx with mixin=0, the user can now identify that the money has been spent, can assume any associated inputs belong to the spender, and can see where outputs are intended to go.
I couldn't help but notice that you have an XMR address in your signature. It amounts to the same thing. Public disclosure and reuse of an address coupled with mixin=0 respending allows (limited) tracing of spends in all of the cryptonote family. The only real difference is that the address disclosed in the blockchain is completely public. I believe that's the intent of the aliases, no? But this is a fairly unimportant distinction in the grand scheme of things. XMR could easily add aliases if they prove successful, BBR could probably rip them out, ... these don't strike me as a fundamental thing to bring to the debate. Correct. I don't believe in sticking this information into the blockchain in arbitrary data appended to tx though, because I think it's bloat and creates races to spam the chain much like races to purchase domain names. |
|
|
|
2) Aliases attach additional, permanent identity pieces to your addresses and should probably be avoided in my opinion.
Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders.
This is a nice feature in BBR. You don't need to use it at all. Alias name is just as anonymous as CryptoNote address. It can not be used to identify the sender if sender doesn't want to. Similarly, who knows Satoshi is? Consider the instance in which a user uploads their alias, and someone sends them a small output, maybe 0.1 BBR. Now, the person watches the blockchain for when this output is spent. If the user with the alias spends it in a tx with mixin=0, the user can now identify that the money has been spent, can assume any associated inputs belong to the spender, and can see where outputs are intended to go. |
|
|
|
I think it is generally helpful for the particulars of these differences to be well-known. Can you provide a reference? Or even just high-entropy keywords?
1) Using the block header hashes as the scratchpad was intended to keep individual miners full nodes, but this was naive and pools simply send the (tiny) headers out to the miners themselves. There is lots of discussion about how to prevent pool centralization in Bitcoin lately, and Boolberry's solution has been criticized as being "the worst of both worlds" (requires lots of extra data to hash, but doesn't prevent pooled/centralized mining at all). 2) Aliases attach additional, permanent identity pieces to your addresses and should probably be avoided in my opinion. 3) The mandatory mixin=n for txouts doesn't solve fundamental issues with privacy relating to ring signatures. Monero has the same issues, but this will be discussed in an upcoming softfork proposal I'm coming up with thanks to some guidance from gmaxwell. Right now, because Monero is mostly used speculatively, it's not really an issue and is probably a boon to trading over the chain. Further, Boolberry's feature attaches identifier information to outputs which may be further used in analysis to identify spenders. |
|
|
|
Is there an advantage to having 64K connections? or would it be better to stop making connections at a hard coded number. maybe overhead resources are small so an extra few thousand connections it not a problem.
BTW it password protection is working for me and I can use the client now.
Thank you also for doing the code audit. making sure it's clean now is a very good idea and should make troubleshooting later easier.
We need to limit max connections in the daemon in future versions, the daemon is very promiscuous and bandwidth intensive unfortunately. |
|
|
|
While I completely understand your points and thoughts, this is actually 100% the wrong strategy. So many engineers and other technology workers make this mistake all the time. They think that its enough to build something superior technically, and the marketing will just happen and success will just happen. I see it all the time in the VC work I do in Silicon Valley. Its a huge error.
Market opportunity is a fleeting thing. VHS beat out BetaMax but BetaMax was much better technology. But VHS won because it was simpler and had much better marketing.
The Monero community and the devs especially, need to understand that time is not a luxury, and that marketing and ease of use are not unnecessary for success. There is only a small window of opportunity here to gain serious momentum and mindshare. After that some other coin (BBR, or new competitor) that has basically the same feature set but with an easy to use wallet and ecosystem that is actively marketed and promoted will win and XMR will be nothing but an also ran.
I love XMR's potential, but until the devs really understand the need for speed and the need for ease of use and the need for active marketing now while the iron is hot, they are in danger of choosing the exact wrong approach to success.
If you want to change the world, then XMR needs to be so easy that anyone can buy XMR and transfer it with no learning of any kind. It just works. If XMR can't do it, then some other competitor will and XMR will lose the window to become number one. Because once a coin ends up being THE coin of choice for anonymous transactions its game over for all the others.
The problem is that the reference code (especially the wallet) is still buggy as all hell and behaves unpredictably. All the CN code has these problems right. Building a GUI wallet isn't the hard part, making it robustly functional is. This is financial software, if things behave unexpectedly people lose their money and their shit, which is much worse for a cryptocurrency in the long run. There are a couple alpha GUIs right now, probably the most mature is this Windows one if you want to play with it: https://github.com/Jojatekok/monero-client/releases |
|
|
|
What is the benefit of adaptive block sizing?
Mostly it prevents rapid spam attacks and also high orphan rates when txs initially accelerate on the network. Additionally, it provides a mechanism to reduce inflation through blockreward penalty (although we capped that and are working to optimize that section of the code now). There are downsides, namely that it allows miners to basically control the size of blocks, which the Bitcoin core devs don't like. gmaxwell thinks it should be dumped, smooth wants to proceed with it and see how well it works for us. Less inflation means high price vs fiat typically. |
|
|
|
|
Adaptive block sizing means right now it's hard to get money around in XMR chain because it is saturated. However, over the next hour the blockchain will expand its blocksize and this will be less of an issue. Please wait for your tx to be included in the blockchain.
|
|
|
|
|
Cunicula isn't a developer, he's an economist... I doubt he's ever written a line of code, but he was a pretty nice guy when I met him.
I'm not sure how much he said then is relevant now, but PPC is still around.
|
|
|
|
Should being the key phrase ... However 2.0 == fail (same error).
keep trying smaller amounts |
|
|
|
Greetings Anybody got a clue as to how out get coin back out of the wallet? I've got the CLI v0.8.8 from FP but any attempt to send coin to an Exchange (which requires a Payment ID) gives the below error. Test transfers without a Payment ID result in a successful send (according to the wallet) but the coin never got there.  So is the transfer buffer just to small? Or is there a way to actually use/send the coin? You need to send smaller coin amounts because of dust from pool Send 2.5 and 2.0 and it should be ok |
|
|
|
Is there any reason I would add no Mintpal XMR?? or is everything ok
The chain itself is working fine, whether or not Mintpal adds it is up to them. |
|
|
|
I'm sorry for offtop, but will you do another pizza-dilvering event in the future for monero?
I must to ask it because of my nickname
Oh, yeah, I need to get those out, thanks for reminding me. As to more pizza, not sure. |
|
|
|
A bug was identified with deterministic wallets. It stems from the original ByteCoin code. https://github.com/amjuarez/bytecoin/blob/baaa3484271e11398790bbf01ee4d7b19c68e3bb/src/wallet/wallet2.cpp#L162-L194Basically, when you create a wallet it only bothers to scan the blockchain from the time at which your wallet was started from. However, when you restore a wallet from your deterministic seed, it does the same thing because it doesn't know your wallet was created earlier. This caused some users to think they lost their funds when restoring, however all funds are safe, the wallet just isn't scanning all the blocks it should for your funds. We are going to deploy a fix ASAP |
|
|
|
zone117x has announced that he would like to begin work on a thin client. <zone117x> good news for y'all. development for a thin-wallet and corresponding service will be in development soon. send/receive XMR without having to run a full-node/blockchain while keeping your coins local (wallet private key never leaves your system). |
|
|
|
|
Show Posts
