Bitcoin Forum
December 02, 2022, 03:42:56 PM *
News: Reminder: do not keep your money in online accounts
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: Kencoin ICO - your thoughts? on: September 08, 2017, 02:15:05 PM
I looked into the founders social media pages. They check out & seem legit. Kencoin could be a good investment
2  Other / Off-topic / Re: What is the ideal college course? on: September 07, 2017, 10:12:56 AM
I dropped out of college towards the end of my degree after bitcoin got big. Luckily I had bags and now I mostly just chill.
3  Bitcoin / Development & Technical Discussion / Re: Building headless Bitcoin and Bitcoin-qt on Windows on: June 18, 2015, 04:06:13 PM
Thanks, nitrogenetics for keeping this guide updated; it did help me track down an issue trying to compile a coin based on Bitcoin 0.8. Though I noticed a few things that probably should be noted from the shift to version "L" of OpenSSL 1.0.1 from version "J":

In the 0.8 headless client modifications to the "makefile.mingw" file, you still have references to "openssl-1.0.1j" that should be updated to "openssl-1.0.1l".

Also, when compiling OpenSSL (step 2.1) after running the "./Configure" command, the output from that command suggests running "make depend" first, before running "make", which should probably be part of the instructions? My compile of OpenSSL actually failed out, while parsing the "test" directory (ideatest.c:1:1: error: expected identifier or '(' before '.' token, ../crypto/idea/ideatest.c), but all the source files got properly built before that, so it didn't affect final compilation. Is there a flag to turn off running tests of OpenSSL?

Its mentioned a few times to make sure various things are on in your PATH variable, and an example is shown in the compiling the GUI/Qt step of how to do that in the command prompt, but it's not shown for the MSYS shell; it might be useful to spell it out specifically that to add the MinGW binaries to your PATH in MYSYS, do:

Code:
PATH=/c/mingw32/bin:$PATH

But to add them to your PATH in a standard command prompt (which is needed for compiling the QT 4.8 library), do:

Code:
set PATH=C:\mingw32\bin;%PATH%

Also, compiling QT 4 requires Perl be installed; my Windows 8.1 box didn't have that by default, so a link to http://www.activestate.com/activeperl might be useful.

You mention commenting out the "genleveldb.commands" in the "bitcoin.pro" project file, but if you do that, you should probably also comment out the "QMAKE_CLEAN" line, which attempts to delete the "libleveldb.a" file when a "clean" action is run.
4  Other / Beginners & Help / Re: BTC Vault - Secure Bitcoin Live-CD on: December 05, 2013, 01:07:44 PM
Thanks for creating this! I like the transparency and clarity of the "Security" page descriptions of how to check the integrity of the downloaded files; that's a great piece that's missing from some other pre-built ISOs. However, one thing I would like to see is documented the process of creating the ISO from the git source, for those who want to verify it that way (git clone, build, shasum compare to provided ISO files). I see a Makefile; is it as simple as "make"? What dependencies need to be in place on the building system first?
5  Bitcoin / Development & Technical Discussion / Re: Brainstorm the next generation of minikey on: December 04, 2013, 04:51:23 PM
I was starting to think down this road myself recently, and had some thoughts about starting back at the simplest solutions an wondering why they weren't effective:

Namely, for the situation of a paper wallet or physical object (coin, etc.) being created by someone else, why not use a HMAC_SHA256 function? That would look something like:

Client picks a password p and a salt S. Using HMAC_SHA256, with p as the key, signing the message S, an output hash k of 256-bit length then becomes a private key for a Bitcoin address. The Client derives the public address K, and sends S and K to the printer to be printed onto the physical wallet. When the client receives the (amazingly gorgeous!) wallet back, they can add p to it before storing it safely, ensuring anyone who was in possession of it could easily derive k from p and S, or leaving p a secret, making it a "brainwallet" that only the client could unlock.

Variables summary:
  • p Private password picked by client
  • S Private salt, shared with wallet creator
  • k Address private key, derived from p and S
  • K Public address of k
This would be vulnerable to brute-force attack by the wallet printer (they need to crack p since they know S), or in the case of a paper wallet where S is secret (covered by hologram or inside the physical coin), someone holding that paper wallet would need to crack S since p is visible on the wallet. Meaning the strength of p and S would need to be rather strong.

So, to prevent people from picking "puppies" as their password p, what about employing BIP39 for this? Make both p and S a random 128-bit number, which commonly is expressed in mnemonic form of 12 words. 128 bits is 16 bytes, which is 32 characters long expressed in Hex, which fits nicely in a 3-Q QR code (Version 3; 29x29 cells, Q-level error correction; 25% error recovery). The wallet can have a QR code for S and/or its mnemonic or base58-encoded, both optionally covered by a hologram by the printer. The client then can print the mnemonic of p on it, as above. 128-bits is the same strength as BIP32 and Electrum chain codes, which should be strong enough on their own, to resist a brute-force attack.

Alternately, make the bit-length of p and S smaller, and use Scrypt on the HMAC_SHA256 to ensure brute-forcing is still hard. If p and S were 64-bit, that would be a six-word mnemonic, 16 hex characters (fits in a 1-Q QR code; 21x21 cells), or 11 base58 characters. Would Scrypt parameters of something like r=8, p=1, N=1024 be a good starting point?

So, from your list of requirements, thinking S is really the "minikey" in this scheme:
  • 30-character code that starts with P (so, 29 random characters): No, this would be identifiable as a two-part key, both halves presented as a BIP39 (or similar) mnemonic.
  • The ability for a person to create the minikeys without knowing the password: Unlike the current minikey scheme, this one doesn't require "mining" for one, but the creator only has half the key required to get k
  • Uses scrypt for hashing the password and deriving the private key: Yes.
  • Tunable scrypt parameters: Yes. The Scrypt calculation would be done by the client before requesting the wallet be created/printed, so could be whatever they want.
  • The ability for the costly scrypt step to be outsourced: No.
  • Typo detection on the password, that requires all the expensive computation to be done to know whether the check passes or fails: Yes to typo detection (BIP39 has a checksum feature), no to expensive.
  • About 169 bits, 156 of it random: Two 64-bit half-keys would only be 128 bits of entropy, but that could be adjusted higher.
So, not a perfect match to your requirements, but very simple. The one other downside to this method is that if the client wants dozens of wallets created, they need to pre-calculate all them in advance (unlike, say the BIP38 using EC multiplication and a sequence of multiple addresses). As far as evaluating your requirements, I don't value the "outsourcing the Scrypt generation" as highly. I do think this simple schema could be improved by adding in metadata to indicate the Scrypt parameters used (as part of p) and a flag as part of S to indicate it is half a key (starting with some flag, like the 'P' you proposed; making S best expressed in base58 rather than mnemonic), needing some p to complete (and some hash/checksum of p to pair them back up if separated). Having 156-bits of entropy I think is okay; I think it should be somewhere in the range of 128-160 bits (if 128-bits is okay for an Electrum/BIP32 chain code, I'd set that as the bottom limit).

Any glaring holes with this rather simple option?
6  Economy / Gambling / Re: BitMillions.com- More than ฿ 1,400 in Prizes - Play with only ฿ 0.01! on: November 20, 2013, 09:19:18 PM
Scripting failure on my recent ticket: https://bitmillions.com/tickets/f8c3114c7f4be898a14be6b178a4c1274a1f61ef40c31351b02f2a215a2ee1b8:0

I submitted 0.04044400 BTC, with the intent that I wanted to play 4 times, and pick two of the four numbers for myself (04 and 44). However, the ticket was interpreted as choosing the numbers 00, 04, 04, 44. Yes, those four number pairs are in the bet submission, but that's now impossible for me to win the "match four", since it allowed two numbers to be identical (ticket draws skip identical pairs, for example here: https://bitmillions.com/draws/270663, (click the verify numbers barcode); 57 came up twice and was rejected)!

The system should either have figured I picked 00, 04, and 44 and either picked another number for me randomly, or rejected the preset numbers and picked four random numbers for me.
7  Economy / Securities / Re: ASICMINER: Entering the Future of ASIC Mining by Inventing It on: October 16, 2013, 09:12:46 PM
For those of us castoffs from BTCT.CO who are new owners of direct shares, is there a guide anywhere for expectations of direct-share owners? Namely now to transfer or update our payment address if necessary? I don't see that in the first few posts of this thread, and didn't get that information as part of the transition.

Thanks!
8  Bitcoin / Development & Technical Discussion / Re: btcaddr.me - Bitcoin Address Identicon on: September 21, 2013, 02:29:03 AM
Replying to myself again Roll Eyes, but just for fun if we disregard prefix we can fairly easily match 32 bits:

1KbhFQVEUk8wMVtiuBURZAQ1PXnsDUqcag


1EEwcrjaJkWLLZDuZA2Rhob3aVM8NwY5tR



or 40 bits:

1NcE7wksPMcydG7bfsGsGdjf2ckzXSfw1R


1H26EaqCrbdHZk2SvqvZDfPHqYGbYqQsJj


Not going to try for 48 bits on the CPU, but with OpenCL code on a GPU it shouldn't be bad either.

Interesting; I was thinking there probably aren't enough permutations of a default identicon to cover the huge possibility set for Bitcoin addresses, and that pretty much proves it. This sort of attack could be made less likely by modifying the identicon library with some tweaks. Namely, to not allow so many color variations, so an attacker can't just get a purple color close to the other purple (the biggest weakness, I think), but then those bits of the SHA hash have to be re-used as something else.

The default Identicon is a 3x3 grid, but really there's only three different sprites used (corners, edges, and center) and two colors. If you make only the opposing pairs match (top/bottom, left/right, NW/SE, SW/NE, and center), you've got five instead of three, and each pair could have its own color (net gain of 3 colors), without it looking too messy. I need to sit down and figure out how many bits would need to be re-used if the color palette was reduced... I might put my code where my mouth is on this one, since it seems like a fun project to tackle!
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: June 07, 2013, 02:33:34 AM
That's 74 seconds after the timestamp of 24191. My retargeting math has worked for all the previous retargets, so why did this one go wonky? Was there some different logic in place for this block round that allowed a slightly different difficulty retarget? Is this a rounding error (after multiplying the old target by the actual time spent, do I need to truncate it before dividing it out)?
Block 22175 is 74s before block 22176 (time of block 22175 = 1318761208).

It is related to a bug known as "retarget hole"/timetravel due to merged mining :
https://github.com/namecoin/namecoin/commit/436f571d41cc53844d482eeef0069a3ca94e08f8
https://bitcointalk.org/index.php?topic=43719.0
https://bitcointalk.org/index.php?topic=43465.0 (first post erased...)

So, after block 19200, go back 2016 instead of 2015.
Thanks! That seems to have fixed it, but for right now the three hard-coded IP seed nodes for Namecoin are all refusing connections, so my client isn't finding any peers to connect to. Was there a new version adopted that change the ports or magic bits of network communications?
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: June 04, 2013, 09:22:14 PM
Okay, here's a technical question; I've got an issue trying to get my namecoin port to validate the block at height 24192. That's a point where the difficulty target changes (24192 % 2016 = 0), and it looks to me like the difficulty moved incorrectly, and yet it's in the blockchain as valid.

The logic (as I understand it) for the difficulty changes are: [old target] * [actual time] / [expected time] = [new target].

Here's the old target (what block 24191 has) and the new target (what block 24192 has):
Code:
old target: 000000000000b269000000000000000000000000000000000000000000000000 (bits of 0x1b00b269)
new target: 0000000000006b32b10000000000000000000000000000000000000000000000 (bits of 0x1a6b32b1)

But here's what my math arrives at:
The timestamp on block 24191 is 1319487998. Block 22176 (2016 blocks before 24192, the first one with the difficulty bits of 0x1a6b32b1) has a timestamp of 1318761282. The difference of those two (actual time spent) is 726716, which makes [actual]/[expected] = 0.600790343915344. Hence I get a new target of:

Code:
my target:  0000000000006b2fe50000000000000000000000000000000000000000000000 (bits of 0x1a6b2fe5)

Close, but not quite. Taking the new difficulty that apparently is valid, I get a ratio of 0.6008515185394, arriving at an actual timestamp of 1319488072. That's 74 seconds after the timestamp of 24191. My retargeting math has worked for all the previous retargets, so why did this one go wonky? Was there some different logic in place for this block round that allowed a slightly different difficulty retarget? Is this a rounding error (after multiplying the old target by the actual time spent, do I need to truncate it before dividing it out)?
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 23, 2013, 08:37:31 PM
I got a nodejs implementation able to connect and download the namecoin blockchain up until the merged mining fork at block 19200. Looks like I'll have to delve into the Aux-POW logic to make any more progress.

After diving through source code for quite a while, I think I've finally wrapped my head around the merged mining/Auxiliary Proof-of-Work methodology. As such, I've updated the Merged Mining specification on the Bitcoin wiki to give quite a bit more technical information, and some examples. Some of the existing content was corrected (calling the last attribute of the merkle branch object an "index" was throwing me for a while; it's really a bitmask field, to be interpreted bit by bit, not as an integer index value). Hopefully that helps others who are trying to get clients to validate the Namecoin AuxPOW blocks. And let me know (or just re-edit the wiki) if I've gotten anything wrong!
12  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 18, 2013, 02:30:51 AM
Also, I will accept paying the bounty for a working namecoind as described above even if it doesn't have the merged mining stuff in, as that is something well served afaik with the outdated client.

That is simply not going to work, unless you mean a namecoin fork or alternative.  Namecoin needs merge mining to at least validate the blocks already made with it active, even if you turn it off in this new version.   Merged mining is a forking change.

I just arrived at the same conclusion myself; I got a nodejs implementation able to connect and download the namecoin blockchain up until the merged mining fork at block 19200. Looks like I'll have to delve into the Aux-POW logic to make any more progress.

Updated Mac port, and a gui version for sending coins for windows as well.

--URL REMOVED--

Can you share the source code? Pushing binaries around is dangerous (for users) at best.

Yes.   Binaries from unknown sources are very dangerous.  

It's great there is some new namecoin work being done, but it has to be in the open for all of us to see or else no one will trust it.

Post the source on github or another suitable location and let us all review it.  


The benefits of having a compiled binary is speed and simplicity in that its one file to move around, but then you run into these issues; you need to have a trusted compiler who can GPG sign the results and be trusted by the community. That's why I'm liking the possibilities of a Nodejs implementation; it has the power of server and a client, and doesn't have to be compiled, so is a lot easier to verify it's not been tampered with. The advancements in the Bitcoin source have added lots of great features for wallet manipulation and security, and building on a different platform doesn't take full advantage of that, but those can be added incrementally. I'm glad this thread necromancy has revitalized some developers to come out of the woodwork! Cheesy
13  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 15, 2013, 03:22:49 AM
I've nearly got a port working based on the bitcoinjs-server nodejs library, as well. I've gotten it to connect to the peer network, though it seems there's some difference in how the block difficulty progression is calculated for NMC... Once I get that and add the logic for the NMC-specific Scripts, that will be another option for end users to run locally via Node, and as a web framework for web applications as well!
14  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 13, 2013, 01:11:32 PM
I'll see if i can get it compiled on a Mac OS for you and either tel you what I did or you could try my binary if you like ... what OSX are you on and 32 or 64bit? (also might be able to do it using clang I suppose)
I'm on 10.6.8, trying to use Macports libraries to get it to work. Thanks!
15  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 10, 2013, 07:29:58 PM
Okay, so I can't get a working binary on my Mac right now, but I can delve through the source code, and that has been very enlightening, namely, that Namecoins really are just colored coins! I had thought that the Namecoin alt had modified the transaction structure in some way to handle setting the value of the registered name, but that doesn't look to be the case. Instead, Namecoin uses the Script of the transaction to set a value, and enforces that subsequent "name_update" transactions absorb the most recent unspent transaction of the same 0.01 NMC that was used to initialize the name in the first place. Namecoin usurps a few of the Script constants (namely OP_1, OP_2, and OP_3) and gives them special meaning. It constructs the Scripts to properly validate with the standard Bitcoin parser (it uses OP_DROP to drop off its special values before continuing with a standard transaction Script).

Namecoin's blockchain is at the same speed as Bitcoin's (10 minutes), and uses the same hashing methodology, just the genesis block is based on a different string. That aside, it looks to me that Namecoin's transactions would qualify as valid, non-standard Bitcoin transactions (non-standard because they use different opcodes in their Scripts). As far as I can tell, most all the other changes to the Namecoin source compared to Bitcoin's are to implement the merged mining idea.

So... given that "non-standard transactions" might be entering the community's awareness more, due to 0.8.2 marking microtransactions as non-standard, the question that comes to my mind is why is this an alt-chain at all? The same mining pools that have been convinced to run namecoin pools, could probably be convinced to run pools that accept non-standard Bitcoin transactions (or specific non-standard transactions that conform to a "namecoin standard script") instead, and "namecoins" could become colored Bitcoins with a particular script giving them a data value as well. Is there a strong benefit to having this be a completely separate blockchain?
16  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 10, 2013, 01:17:50 PM
Something to with the boost-filesystem package it seems ... maybe that it wasn't compiled for 64bit?
Hmm, boost 1.53 is installed with the "+universal" variant from MacPorts, and there's no separate boost-filesystem port, so that looks to be it. I do have a /opt/local/lib/libboost_filesystem-mt.a file in that location. I did try running the command with 'sudo' in front, wondering if it might be local filesystem permissions, but that doesn't help either. I'll try re-installing the boost port and see if that helps. Thanks!
No luck; still getting that error. Is anyone else's darwin/osx gcc-fu better than mine and can get a Mac binary compiled? I can muddle my way through C code (I'm a PHP/Python dev, mostly), but all the compiling nuances I haven't gotten my head around entirely.
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 09, 2013, 11:22:58 AM
Something to with the boost-filesystem package it seems ... maybe that it wasn't compiled for 64bit?
Hmm, boost 1.53 is installed with the "+universal" variant from MacPorts, and there's no separate boost-filesystem port, so that looks to be it. I do have a /opt/local/lib/libboost_filesystem-mt.a file in that location. I did try running the command with 'sudo' in front, wondering if it might be local filesystem permissions, but that doesn't help either. I'll try re-installing the boost port and see if that helps. Thanks!
18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 09, 2013, 11:11:24 AM
Really does no one consider the possibility of making the GUI a web application that runs in browser on the users own machine? It would be like running an instawallet on your own computer with the possibility of entering in console commands.
The issue there is the blockchain; in order to do anything, or show the user anything, the web application needs a trusted copy of the blockchain. If it's a locally-running app, most users don't have a database program running on their local machine for a web app to hook into. As a public website that users can visit (like instawallet, or blockchain.info's wallet) that's very doable (the server also connects to the P2P network and trusts its own database records for users to query), and I mentioned that as something I'm looking into, using node, like the bitcoinjs project.
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 09, 2013, 03:48:23 AM
1) patching latest bitcoind to support namecoin
Right, though it seems no one has a description of how the Namecoin client modified the Bitcoin P2P protocol, not just the RPC protocol, so rebuilding it from scratch would be more difficult. I presume a working namecoin client does allow the "rawtransaction" cli command to show some of the detail in a given transaction structure? (the blockexplorer site for Namecoin doesn't show that level of detail). I'm still struggling to get a working client compiled for my OSX box, so can't check myself.

Can anyone help me figure out why I'm getting this compile error trying to build the client? I'm using Macports for the library installations.
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: May 08, 2013, 02:22:48 PM
Is there anyone that can provide me with a quick tl;dr of the differences between bitcoin and namecoin in terms of communication protocol between peers and wallet format?

I'm circling back on my interest in Namecoin and hitting this roadblock as well. I'm on a Mac, and failed to get the v3.50 version to compile, and the latest compiled binary I could find was too old to be accepted into the current P2P network. The wiki does somewhat document the CLI/RPC commands, but looks to be completely silent on the actual P2P/TCP protocol (effectively, what changed between this documentation of Bitcoin's Protocol, and Namecoin's implementation). If that could somehow be documented, this project could be revived in other client implementations, even if the changes can't easily be rebased onto Bitcoin's latest source.

As some of the recent comments on the wiki indicate, because this alt-coin only has a command-line daemon, and no GUI, and no web-based wallet systems, it's one of the harder alt-chains to just pick up and start using.

I've gone through and created some diffs of Namecoin's source compared to Bitcoin's source at various points, and will try and see if I can muddle through them to figure out some decent documentation on the P2P protocol. If anyone else wants to take a peek as well:

  • Namecoin 0.3.21 changes against Bitcoin 0.1.5: This is from Vinced's repository, and appears to be the first "released" version; the one that is timed about the same time as the announcement that started this thread, compared to the version of Bitcoin it was originally forked from. I use this one as the base since presumably by the time vinced was comfortable to release it, the various protocols and standards were fully fleshed-out. Notably, this is the largest Diff of the set, at 32.1K lines long (some coding efficiencies between 0.3.21 and 0.3.51 cleaned up 10K lines of code?).
  • Namecoin 0.3.51 changes against Bitcoin 0.1.5: This is the current version of Namecoin, from the main "namecoin" github repo, compared to the version of Bitcoin it was originally forked from. 22.2K lines long.
  • Namecoin 0.3.51 changes against Bitcoin 0.8.1: This is the current version of Namecoin, compared to the current version of Bitcoin. 25.6K lines long
Pages: [1] 2 3 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!