Solo mining works like that on most coins: a new address is generated for every mined block.
Does it pull an address from my key pool? Yep when you mined a block solo mining without specifying an address.. It will take one from your key pool I only found it confusing because the address does not show up under "Receiving addresses..." and I would have thought it would do that. You have 100 key pairs in your keypool at any given time.. unless you change the default settings.. anyway these keypairs remain out of sight until needed.. They are needed when you request a new address.. when you have change from an output come back to you.. when you mine a block.. but every time you take one you get an new one added to the pool.. sort of like beer in a cooler.. when you take one out put another one in.. @samsmith16 Thank you. That was a great explanation. Although, I did already know all of that information.  I was not sure what key was used for new blocks. I had thought correctly, as you have confirmed, that it would come from the key pool, but I had expected to see the address in "Receiving addresses..." when the block was found. I was mostly confused by the, "why is it not listed there?" That made me question what I thought I understood. hi there newbie question here, is it possible to mine hold even w/out actual coin in stake?
just downloaded the wallet and start the mining base from the tutorials just want to confirm
if even w/out any coin inside the wallet this mining will work.
@arseaboy You can mine with your wallet. You can only earn interest on money you already have in your wallet. |
|
|
|
Solo mining works like that on most coins: a new address is generated for every mined block.
Does it pull an address from my key pool? Yep when you mined a block solo mining without specifying an address.. It will take one from your key pool I only found it confusing because the address does not show up under "Receiving addresses..." and I would have thought it would do that. |
|
|
|
A forum isn't really the best place for this, but stop overthinking it. Stuff your whole block header, nonce included, in the "key" input that is transformed.
@Wolf0 You are right. I was over thinking it. You never heard of scrypt?
@tromp Honestly, I never actually looked at the scrypt algorithm. Yes, I have had my head in the sand for some time now.  |
|
|
|
... What would you have suggested in place of the current algorithm? ...
A proper KDF would work... many are even tunable to different needs. I never thought of using KDF in this manner. I am assuming that you would be solving for the Derived Key. How would the Key in the KDF function be determined? Would the nonce be represented by the salt value? What kind of function would you suggest to use in operating on the Key? |
|
|
|
Butchered custom algos - even if based on a proven and well-scrutinized primitive - OFTEN fail to do what they intended. For an excellent example of fucking up your goal with a custom cryptosystem because you don't know what you're doing while still using secure primitives, see WEP.
I am aware of the issues FreeTrade had with MemoryCoin. How do you feel about his work on HOdlcoin in comparison? That WAS my opinion on the current PoW of HOdlcoin. I understand what you are saying. What would you have suggested in place of the current algorithm? |
|
|
|
Is that possible to make a GPU miner?
It should be possible. We just need someone like Wolf0 to make one.  |
|
|
|
Butchered custom algos - even if based on a proven and well-scrutinized primitive - OFTEN fail to do what they intended. For an excellent example of fucking up your goal with a custom cryptosystem because you don't know what you're doing while still using secure primitives, see WEP.
I am aware of the issues FreeTrade had with MemoryCoin. How do you feel about his work on HOdlcoin in comparison? |
|
|
|
I found the following thread which I believe answers your question. https://bitcointalk.org/index.php?topic=87509.0I realize the thread is a few years old, but it should give you some idea of the sort of traffic you would be sending/receiving. ... would the traffic from the mining generate any weird looking traffic on IT's end? If so is there any way to mask that traffic? ...
I can tell you that your network traffic would look weird. I am not sure what kind of monitoring software your IT department uses, but any good IT department would be able to identify your network traffic with a little research. The only way to mask it would be to encrypt it over a VPN. You would have to verify with the IT department if your potential actions are against the company's AUP, that is if you were even required to sign one. |
|
|
|
Maybe someone needs to release a GPU miner instead.
I doubt we will be seeing a GPU miner any time soon. GPUs do not receive the same bonus for AES instructions as CPUs do with AES-NI. That is not to say it would not be faster, but that it will not see a magnitude of increase on par with Bitcoin or Litecoin and it will require more power. I'll have fun quoting you if I have time to butcher it with a real implementation  Well, my statement is based on MemoryCoin and the folks that wrote a GPU miner for that. I would personally like to see it done and maybe, with your skills, you can pull it off. |
|
|
|
Where can we go and meet Bitfury personally for the chips?
Do any one of you have an idea of which office of theirs to visit to talk about the chips?
Minimum order is $1M USD I'm aware of that, bro. Can you just help me out with my query? Do they even receive visitors? |
|
|
|
|
I have done this on a Raspberry Pi 1 Model B+ using Minera. I set BFGMiner to work as a stratum proxy and it worked pretty well. However, I am not sure how much hashing power a Raspberry Pi can handle. It may be difficult for even a Raspberry Pi 3 Model B to keep up with your work load.
|
|
|
|
Linus Torvalds... I am not sure he would agree with your application of his quotes, but that is not really on-topic. @mycoinsstore To answer your first question, I have a large stake in MMC2. I have been mining since the beginning of 2014 and I have been following the project since mid-2013.
Your are late dude, it's already MMC3 - look at sources I can change your large stake of mmc2 to mmc3 at good rate. MMC2 is a reference to the current MemoryCoin blockchain. There is no such thing as MMC3. You are confusing the wallet version with the blockchain. MMC2 has a pre-mine of ~7.32%. The first block in the MMC2 blockchain is comprised of all MemoryCoin Beta balances as of block 8820 on the MMC1 blockchain (~6.2%) and ProtoShares (~1.12%). https://bitcointalk.org/index.php?topic=370806I also currently represent ~40% of the MMC2 network hashrate and I can easily increase my hashrate by at least 300%. I think that should answer your remaining questions about my interest in MMC2 and whether or not I am here to argue.
Oh, really? And how can you measure this percents? Please, provide us this great formula. On average, I find ~20 of the last 50 blocks. 20 / 50 = 0.4 = 40% I would like to get p2pool working again, but we need to coordinate our pools and properly bootstrap the sharechain. I am prepared to host a node that will function as a bootstrap address. I think that I can fork KillerByte's p2pool code and make the necessary changes to get things working. However, one problem might still remain. Did Delinquency and KillerByte ever solve the grant block issue with regard to p2pool? I am still looking over both Delinquency's and KillerByte's work to determine if the problem still exists, but I have been unsuccessful so far in identifying if it was actually resolved.
I agree. But, I don't understand what you mean in "coordinate our pools and properly bootstrap the sharechain" ? I already have such node and I don't think that mmc blockchain has a lack of nodes. About KillerByte's p2pool code - it's works and worked always. What do you want to change? About grant block problem - this is still exist and can be eliminated (maybe I'm wrong) only by eliminating a "grant block" in sources. Moreover, it is unclear to whom these "grant blocks" should belong now? Do you understand how p2pool works? I am specifically talking about p2pool nodes not MemoryCoin nodes. We can both run p2pool nodes, yes. However, our nodes will not be working on the same sharechain. In order to fix that, we need to update KillerByte's code with new bootstrap addresses and bootstrap the sharechain on one or two nodes. Once that is complete, anybody can add a new node if they want and we will all be working on the same sharechain. The grant block issue to which I am referring was p2pool's inability to submit a valid grant block. There is a grant block every 80 blocks. If the problem was never fixed, the network may have issues with getting stuck on grant blocks. I would also like to get the wallet updated. At a minimum, we need to update the seed nodes so that new folks can sync their blockchains without manually adding nodes. We will also need to compile new binaries for both Windows and OS X. I think that we need to put-off any discussion of updating the wallet to current Bitcoin sources.
I don't think so. Do you see any problems with wallet synchronization or lack of nodes? I can't see such problems. I am not talking about major source code changes. There are at least a dozen invalid bootstrap addresses in the source code. The wallet needs to be updated with new bootstrap addresses. The final issue we have is with YAM. After we get p2pool back on track, we need to contact yvg1900 and request that he update our p2pool addresses in his next update. I have a working hack that enables me to use YAM now, but I would prefer to get it properly fixed so that yvg1900 gets his 2%.
Yam works without any hacks now. The only issue is a greed of his author, who hard-coded nodes (dead now) and closed YAM sources. So, one should restart it every 8 hours or ~400 shares. A very simple "hack" with a scheduler. That is still a hack, regardless of how simple it is, and it is required in order for YAM to work continuously. You appear to be arguing with me simply to argue. The only difference is that you want something for nothing. |
|
|
|
Priceless...
Somehow, we got way off-topic.
Not really. The point is p2pool was written in python when mining was just about building a simple shelf where it suited the job perfectly with the minimum amount of effort. Unfortunately these days building a simple shelf doesn't cut it. Point taken. |
|
|
|
This never gets tired, even if it does misspell assembly  Priceless... Somehow, we got way off-topic. |
|
|
|
So you're saying you agree with everything I say, yet you still maintain your position? Right  I said, "I do generally agree with your statement" and that is definitely not the same thing as agreeing with everything you say. Forget maintainability, how about the type/level of expertise that it takes to use the language competently to begin with? It takes genuine comprehension of broadly non-abstract concepts (like pointers), as well as that of abstract concepts like template functions or lambda logical operations. You could train perhaps 10 people to write good Java in the time it takes to train 1 person to write good C++.
How about the readability of the code? Fortran or Cobol are the only tools you can use for certain jobs, and they're difficult to read for a stranger to those languages.
What about development time? If you're writing software without fail-safe requirements, do you really need to spend the time/money on using a low-level language? You could end up spending 90% of that time/money looking for memory leaks.
So, come on now. You can't reconcile "some languages are better than others, absolutely" with "well, some are better suited to a given development context, others to a different context". That's what I call contradicting oneself.
I think you are missing the intent of my original inquiry about Bitcoin and C++. It was never intended to be an analysis of the languages used or not used, but an analysis of the individuals and their choice of a particular language over another. Additionally, I only implied ASM was better than other languages, absolutely. That statement was made in the specific context of "potential for most optimal code at run time" and I thought you would have understood that based on the sarcasm in your original reply. |
|
|
|
That goes without saying.
No it doesn't, I was being sarcastic. Your sarcasm was not lost on me; however, it does go without saying. It is well known that higher level programming languages have a tendency to add their own little nuances that when compiled to machine language can contribute to less optimal code. The effects can be negligible or they can be significant. It all depends on the programmer's mastery and understanding of the used language in order to minimize the potential effects. There are no "better" and "worse" programming languages in the abstract, only good choices for specific cases.
I do generally agree with your statement and as kano pointed out "maintainability" is a major factor especially when dealing with larger and more complex programs. Do not confuse me with those individuals that ride the python hate train. I happen to like python personally and I use it frequently. |
|
|
|
Most projects, like Bitcoin, don't even care.
That is what I thought you were going to say. |
|
|
|
why on earth is Bitcoin written in C++? I thought C would have been the first and better choice.
Hard lol at "better" and "worse" programming languages. Presumably all code for all devices would be "better" if it was written in machine code? That goes without saying. However, I would think a program as large as Bitcoin would be pretty hard to exclusively code in assembly. Add to that, the number of programmers that code in assembly is also quite small. |
|
|
|
|
Show Posts
