Seems to me that additive vs multiplicative derivation is not the point. Instead it's about how i and c_par are combined. Using c_par^i instead of i*c_par looks different at first sight.
I don't think that c_par^i would give you pseudorandom keypairs. These thought experiments didn't explicitly specify how to derive c_i from c_par, but it appears that you would be claiming that the sequence ((c_{i-1})^i for consecutive i=1,2,3,... is indistinguishable from random data, which isn't true. If we cannot argue that the sequence is pseudorandom, then we cannot prove that we're secure against related-key attacks. So the bottom line is that we'd have to stick with HMAC-SHA2 anyway... |
|
|
|
I'm not sure that I understood your use case, could you please explain the exact scenario more clearly? if you had an ancestor chaincode and pubkey, then you can derive the descendant chaincode and there's no necessity to encrypt and send it to you, and if you don't have any ancestor chaincode then an encrypted chaincode must be sent to you, no?
Maybe we do gain some security by having ci depend on Kpar, because commonly just the hashed address of Kpar is published (until the coins get spent).
Scenario is this: Server A is holding (K_par,c_par). Server B is being set-up in a different location and is supposed to hold (K_i,c_i). All chaincodes are to be kept secret by the servers holding them, i.e. c_par shall only be known to A (not B) and c_i shall only be known to A and B (no third party). It is irrelevant here who knows K_par and K_i. So B does not derive anything itself. Instead, A does the derivation of (K_i,c_i) and sends the result to B. Of course, the communication of A to B must be authenticated. The point is that on top of that at least c_i must (in the general case) be sent in encrypted form. So in this scenario, why wouldn't you need to send c_i in encrypted form with your proposal? |
|
|
|
I suggest to set and serialize maximum i for each extended key. Such serialized string would define the wallet keys without the need of a regular backup until maximum number of keys not exceeded.
Huh? Why would regular backups be needed? The major advantage of deterministic wallets is that backups aren't needed (see here). Assume you lost your wallet storing the unspent transactions, but you have the root key for the BIP32 generator from a cold store. Theoretically nothing is lost since you can scan the block chain for all outputs that can be spent with descendants of the root key, but practically you are not able to do this if you do not know what sequences were used. Therefore you either have to backup the sequences used or simpler set a limit to them in beforehand that is a practicable magnitude for a scan. As Pieter mentioned in the link that I gave you, it should be very practical to scan in mostly all cases of wallet layouts, the branching factor and depth are quite tiny. The assumption there is that if a key with a sequence number is not on the block chain, then higher sequences were not used, right? I think that would not hold. A shop usually offers unique addresses to receive payment for individual orders. Some orders never get paid, therefore their key will not be present in the block chain, however keys with higher sequence number might be. A reconstruction of the wallet would fail at such a gap. Right, good point. I still believe that for the default wallet layout (subaccounts at level 1 and linear path for each subaccount) and for other non-pathological layouts, you could let your computer run for a couple of hours and retrieve all your privkeys, because the depths of the branches (including branches that have keys that were never active on the blockchain) would be quite small. I'd say that if the user chooses a peculiar wallet layout, then it's up to him to consider whether future backups might be important. Furthermore, the client software could let you do "public-insensitive" backup that contains just your wallet layout (just the indices i, or the indices i and the pubkeys) which doesn't contain any sensitive info (chaincodes and privkeys), so you could backup just the layout from time to time, if you wish to be extra safe. |
|
|
|
With the additive variant, don't you get I_L*G from parent and a child pubkeys, rather than I_L itself? I'm still not sure what are the advantages of the multiplicative variant.
We actually just had a discussion about this, and I'm in favor of changing this. The proposal would be: - k_i = k_par + I_L
- K_i = K_par + I_L*G
I've been holding back on changing this, as speed wasn't a priority really. However, it is a lot easier to do the required operations for public derivation in constant time, than for the multiplicative case, which means it's easier to secure against timing attacks (and we are, very intensively, dealing with private material here). Also, it means you only need almost the same primitives as needed for ECDSA in the first place. It is not less secure, as you still need to solve the ECDLP to find I_L from I_L*G (=the public key, which is exposed). Assuming a weaker version of the scheme, where it's just K_i = K_par + (i*c_par)*G, and assuming there is a transaction with inputs corresponding to i values i1 and i1+1, and a transaction with values i2 and i2+1, an attacker could detect these were created by someone using the same chain code twice. This would not be possible in the multiplicative version, and also not in the real scheme where the 'tweak' I_L is computed using an HMAC. Anyone objects to changing this? Why does constant time public derivation give security against timing attacks? Isn't it the case that public derivation doesn't use the privkeys, and therefore cannot leak privkeys? Maybe you meant security against leakage of just the chaincodes? I probably simply misunderstood what you're saying there, so it'd be helpful if you explain where exactly we need protection from timing attacks. Yes, obviously with a variant that uses K_i=K_par+(i*c_par)*G you could detect c_par*G from the sub-branch with i1,i1+2 compared to the sub-branch with i2,i2+1, and maybe you could do much worse stuff as well. The OP also uses the safe version with hash(seed|i) to derive the next values. You can see that the formal proof in post #62 fails for K_i=K_par+(i*c_par)*G because we wouldn't claim that the r_i that's used for (sk_i,pk_i)=keygen(r_i) is pseudorandom. As you mentioned in post #103, if the attacker learns I_L then it doesn't seem like such a big deal, and as mentioned here the attacker needs to solve ECDLP to learn even just I_L, so the additive variant appears to be provably secure, as far as I can see. But of course it wouldn't hurt to show the finalized BIP32 to some elliptic curves crypto experts and ask for more peer review, before including it in the Satoshi client. |
|
|
|
I suggest to set and serialize maximum i for each extended key. Such serialized string would define the wallet keys without the need of a regular backup until maximum number of keys not exceeded.
Huh? Why would regular backups be needed? The major advantage of deterministic wallets is that backups aren't needed (see here). Assume you lost your wallet storing the unspent transactions, but you have the root key for the BIP32 generator from a cold store. Theoretically nothing is lost since you can scan the block chain for all outputs that can be spent with descendants of the root key, but practically you are not able to do this if you do not know what sequences were used. Therefore you either have to backup the sequences used or simpler set a limit to them in beforehand that is a practicable magnitude for a scan. As Pieter mentioned in the link that I gave you, it should be very practical to scan in mostly all cases of wallet layouts, the branching factor and depth are quite tiny. |
|
|
|
I'm still hoping to hear some explanation on why the multiplicative variant is advantageous.
It seems to me that it makes sense to re-consider this issue before BIP32 is finalized.
Can someone precisely specify the additive variant of the CKD function? I'm fairly certain I know, but I don't want to end up missing a detail and evaluating something else. It's described by gmaxwell in the OP of this thread. As currently in BIP32 you would still have I=HMAC-SHA512(Key=c_par, Data=K_par || i) And then: k_i=k_par+I_L K_i=K_par+G*I_L c_i=I_R |
|
|
|
Regarding using addition instead of multiplication: we switched to multiplication at some point, but I can't remember why - the only thing it adds is removing the ability to compute I_L from a parent and a child pubkey, which doesn't seem to gain you anything.
With the additive variant, don't you get I_L*G from parent and a child pubkeys, rather than I_L itself? I'm still not sure what are the advantages of the multiplicative variant. The additive version would be faster because the "fast exponentiation" algorithm that computes I_L*G can use pre-computed values of x*G for small x. I believe OpenSSL does something like that. Not saying that speed should be of any concern here, though.. I'm still hoping to hear some explanation on why the multiplicative variant is advantageous. It seems to me that it makes sense to re-consider this issue before BIP32 is finalized. |
|
|
|
I suggest to set and serialize maximum i for each extended key. Such serialized string would define the wallet keys without the need of a regular backup until maximum number of keys not exceeded.
Huh? Why would regular backups be needed? The major advantage of deterministic wallets is that backups aren't needed (see here). |
|
|
|
Now a BIP32 specific question:
Why are the child chaincodes derived from both the parent pubkey and the parent chaincode rather than just from the parent chaincode alone? What about this derivation:
K_n:=H(c_par||n)*K_par
c_n:=H(H(c_par||n))
where H is some cryptographic hash. Looks easier to me and doesn't require 512 bit digests. Am I missing some point?
What do you gain by not using all available data? I consider using one 512-bit hash much more elegant than doing several 256-bit hashes. Seeing that some interna of BIP 32 are being re-discussed, I would like to bump this comment of mine from several month ago. Sorry for repeating myself, but I thought that new applications or use cases, and therefore new opinions, might have come up in the meantime. This question/suggestion is about the "public derivation". Instead of I = HMAC-SHA512(Key=cpar, Data=Kpar || i) (with Kpar = kpar*G, EC multiplication)
Split I into two 32-byte sequences, IL and IR.
ki is equal to IL*kpar (mod n).
ci is equal to IR.
why don't we use IL = HMAC-SHA256(cpar,Kpar||i)
IR = HMAC-SHA256(cpar,i) the difference being that ci depends only on cpar and i (as before) but not on Kpar anymore. The advantage that I see with having ci independent of Kpar is that it opens up the possibility of updating all extended pubkeys in the tree (by updating the root extended pubkey) without touching the chaincodes. Consider a hierarchy of servers where each server holds the extended pubkey corresponding to its position in the hierarchy. Note what is required when a server B receives his extended pubkey from the higher level server A. In the communication between A and B the pubkey-part of B's extended pubkey has to be authenticated (if B uses the wrong pubkey, money sent to it will be lost) whereas the chaincode-part has to be encrypted (by default chaincodes are to kept secret). In an update throughout the whole tree we could spare us the encryption part of that communication (if ci was indepent of Kpar) because the chaincodes remain unchanged. Countering the above cited comment: what do we gain by having ci depend on Kpar? I'm not sure that I understood your use case, could you please explain the exact scenario more clearly? if you had an ancestor chaincode and pubkey, then you can derive the descendant chaincode and there's no necessity to encrypt and send it to you, and if you don't have any ancestor chaincode then an encrypted chaincode must be sent to you, no? Maybe we do gain some security by having ci depend on Kpar, because commonly just the hashed address of Kpar is published (until the coins get spent). |
|
|
|
Hello all,
I've made some changes to BIP32 to deal with the issue of revealing a master key by exposing both public parent and private child. The change is important (the child key derivation function changes), but it's maximally compatible with the previous version. In short, it means you can now select whether you want "public derivation" (the older, type-2 style) or "secret derivation" (safer, type-1) in each step, and the default wallet structure uses secret derivation for deriving account keys from the master key. This means that a leak of a secret account key (or below) cannot result in revealing the master secret.
As I don't like encumbering the key derivation with information about wallet structures, the derivation type is not hardcoded but can be selected at each stage individually.
Any comments from iddo, or other people?
Very nice, I like your BIP32 modifications with type-1/type-2 derivation according to the highest bit of the index. it could give flexibility with scenarios that ErebusBat mentioned, something like person A giving person B that he trusts the ability to derive a branch (with privkeys) in his wallet, and then person B wishes to give an untrusted person C the ability to derive pubkeys in a sub-branch, so to enhance security he can break the homomophism link by doing type-1 derivation (person B couldn't have done the type-1 derivation if it was only possible at depth=1 of the "subaccounts", because he's not trustworthy enough to have access to that depth, and besides keeping the layout of extending the particular branch instead of starting a new subaccount could be useful for accounting and so on). Probably there would be more interesting use cases than this one, that I haven't thought of. I suppose that with this updated BIP32, some of the complexity will be transferred to the people who should do GUI design for wallet layouts  As discussed, it's important to do the secret type-1 derivation from the master node (depth 0) to the subaccounts (depth 1), since if the master node leaks then the entire wallet leaks. So the derivation from depth 0 to depth 1 should be type-1 by default, and maybe if you wish to be extra safe (about preventing people from shooting themselves in the foot) then you should specify that type-2 derivation from depth 0 to depth 1 isn't allowed according to the BIP32 standard, and enforce that in the Satoshi client. BTW, with the updated BIP32, I guess that there's no need to save the initial entropy S in wallet.dat ? |
|
|
|
I'm going to explain this like you where 5 years old:
I, my son, his children, will _personally_ track 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd for all eternity, no matter how many addresses the value is being sent to.
The value originating in 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd is for all future marked in our collective consciousness as stolen money.
Nothing else matters, I could create a service where you can store stolen addresses, but that is COMPLETELY IRRELEVANT.
NO ONE will EVER take money from 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd, period.
Case closed.
Let's say for example that the thief uses localbitcoins.com and meets some innocent buyer on the street, transfers those 934 stolen BTC to a fresh address of the buyer (e.g. via smartphones), and in exchange the thief receives dollar bills from the unsuspecting buyer. What do you and your son and his children plan to do in this case? Unfortunately, in reality the thief doesn't even have to bother that much. He can simply deposit the stolen BTC in MtGox, go through the AML verification procedure, and withdraw USD or whatever currency that he prefers. So even though MtGox will know the identity of the thief, they will not reveal it because of legal considerations, unless Graet could produce a court order (and it's highly unlikey that he could, because the thief is probably in another country, and efforts to involve Interpol for this amount of stolen money will hit a brick wall). So bitcoin really is for hackers, thieves and con-men. everyone is getting screwed over left right and centre. That's unfair towards Bitcoin, in the scenario with localbitcoins.com the fault is actually with the dollar bills. I suppose that rupy and his son and his son's children could ask that unsuspecting buyer whether he remembers the serial numbers on the dollar bills that he gave to the thief, and continue to track down the thief this way. But obviously the buyer wouldn't have a clue about the serial numbers of his USD, and even if he did, tracking down the places where those dollar bills were spent is a futile exercise. |
|
|
|
I'm going to explain this like you where 5 years old:
I, my son, his children, will _personally_ track 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd for all eternity, no matter how many addresses the value is being sent to.
The value originating in 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd is for all future marked in our collective consciousness as stolen money.
Nothing else matters, I could create a service where you can store stolen addresses, but that is COMPLETELY IRRELEVANT.
NO ONE will EVER take money from 16cDeEFn6sraUEJrDCt2Yg3r7j2oazSYEd, period.
Case closed.
Let's say for example that the thief uses localbitcoins.com and meets some innocent buyer on the street, transfers those 934 stolen BTC to a fresh address of the buyer (e.g. via smartphones), and in exchange the thief receives dollar bills from the unsuspecting buyer. What do you and your son and his children plan to do in this case? Unfortunately, in reality the thief doesn't even have to bother that much. He can simply deposit the stolen BTC in MtGox, go through the AML verification procedure, and withdraw USD or whatever currency that he prefers. So even though MtGox will know the identity of the thief, they will not reveal it because of legal considerations, unless Graet could produce a court order (and it's highly unlikey that he could, because the thief is probably in another country, and efforts to involve Interpol for this amount of stolen money will hit a brick wall). |
|
|
|
1. Add a new requirement to the Litecoin chain such that a valid Litecoin block must contain either a record of the most recent Bitcoin block header hash, or a repeat of the hash found in the prior Litecoin block (with a limit of repetitions). Litecoin blocks that contain outdated Bitcoin intelligence should be disfavored by nodes capable of detecting that. Further impose the requirement that Bitcoin block headers must be represented contiguously in the Litecoin chain - Bitcoin blocks cannot be skipped (which shouldn't be a problem, when Litecoin blocks happen 4x as often as Bitcoin)
2. In the event there is an active Bitcoin block chain fork, the requirement is loosened such that the Bitcoin block header hash requirement can be satisfied by any leg of the chain, not just the one Bitcoin considers valid.
3. Add a feature to Litecoin clients that allow Litecoin users to decide to prefer or not-prefer branches of a Bitcoin fork while one is in progress. The default for this should always favor the Bitcoin leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitcoin block chain. The user/miner/pool-op should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing Bitcoin blocks.
This general idea of yours for sync'ing the Bitcoin block header hashes into the Litecoin blocks is an interesting suggestion. I failed to understand why would we need "a repeat of the hash", according to your suggestion isn't it true that the next Litecoin L_0 block will either include the next-needed Bitcoin block B_0 hash or the last Litecoin block L_1 hash, so after L_0 was generated, the following Litecoin block should include either the header hash of L_0 or the next-needed Bitcoin block, so there are no repetitions? Actually, wouldn't it be better to require that the next Litecoin block must always include the header hash of the previous Litecoin block, and optionally also to include the next-needed Bitcoin block header hash? What you said about "any leg of the chain" is a bit unclear, nodes aren't required to keep competing legs (a.k.a. branches). I think that what you meant is that if the node sees that its preferred Bitcoin branch disagrees with the branch continuation of Bitcoin hashes inside the Litecoin blocks, then it should still accept these Litecoin blocks, as long as that different Bitcoin branch is valid (even though it isn't the longest Bitcoin branch according to what the node gathered while listening on the Bitcoin network) ? About allowing users to decide to prefer or not-prefer branches, I've written before in another context that I think that it's a terrible idea: It sounds risky to allow each user to manually select which branch to use, instead of automatic rules that all nodes follow. If enough clueless users make a mistake, then the blockchain forks and the situation might escalate, because people in different forks begin to have financial interest to stay in their fork?
|
|
|
|
(2) The requirement of at least some coins (very large amounts as the chain matures) that are 90 days old in addition to 51% of the network hash rate. The first addresses any potential failure of SHA2-256, while the second addresses double-spend attacks created by short forks of the chain. In this way the hybrid PoW-PoS system is a better solution to the byzantine consensus problem as far as I can tell.
Your PoS idea is very similar to cunicula's ABAB system, that we discussed in the PoA thread (see https://bitcointalk.org/index.php?topic=102355.0 , last post about it is #129). We have abandoned the ABAB sort of systems both because they can be even less secure against double-spending attacks than pure-PoW, and because we've come up with a much better system (cunicula removed from the wiki his old protocol that ABAB is based on, and replaced it with a complicated variant of our best PoA protocol, the straightforward PoA variant is described in post #158 of the PoA thread). You appear to have quite interesting ideas that are unrelated to PoS (though I haven't considered them carefully yet). Having PoS in a new cryptocoin also implies problems with stakeholders' incentives to participate versus fair initial coins distribution, not as much of a problem as ripple has with doing the initial coins distribution (because your protocol is mixed with PoW), but still. I advise you to either drop PoS and focus on your other ideas, or consider the implications of PoS more carefully by reading the PoA thread etc. It'd be a pity if it turns out that your ideas are useful, but your entire effort will fail just because the PoS component was unsound. I'm available for further discussion (also on freenode irc) if you'd like. |
|
|
|
An alternative might be to change the scheme so that the main trunk of a deterministic wallet does not have the homomorphism, only further branches from that do. This would greatly confine the leakage there, and also make it more intuitive: leaking the private key for any "subaccount" (or whatever you want to call it) leaks that subaccount. This may be a way to get both properties.
I like this idea. And in fact, with this idea of yours we can still preserve the important property where your initial wallet.dat backup can always restore all your future privkeys, including privkeys that belong to a "non-homomorphic" subaccount that you created after your initial backup: instead of doing HMAC-SHA512(key="Bitcoin seed", msg=S) to derive the master privkey and master chaincode as BIP32 specifies, we can do HMAC-SHA512(key="seed #i", msg=S) to derive master privkey&chaincode for each subaccount #i, and since the random seed S is stored encrypted and SHA2 is a one-way function, this is secure in the sense that leakage in subaccount #i_0 doesn't compromise any subaccount #j for j!=i_0 (the user will need to provide his wallet password when he wishes to create a new subaccount, which is fine). But the homomorphism is really important and enables many valuable use-cases. Right now the need to have private keys online to accept payments is actively getting people robbed. The need to have static addresses for donations and reoccurring payments is actively and materially compromising privacy. The reversible privkey leaks are only applicable to a subset of cases where people would otherwise be robbed completely.
Yes, I wholeheartedly agree that type-2 derivation is really great and that its benefits vastly outweigh the potential risks. All that I'm trying to get across is that wherever we can make design decisions that minimize the possibilities of users shooting themselves in the foot, it's a good thing to do it, instead of assuming that the users will be prudent and then telling some user who lost his coins that he had to read the "fine print" on the risks that key homomorphism. |
|
|
|
Assuming all chain codes are known, if private key m/i/j is known, :
3. are every private keys under m/i/j-1 known? (The answer should be no if it followed the Armory model)
That appears to be false, see post #56 and this post. So if we can reasonably expect that such use cases will be common in the future, then maybe the BIP32 design gives users too much of an opportunity to shoot themselves in the foot? Instead, if the derivation function would be one-way (like in Armory), then only the branch starting with the chaincode that you gave the 3rd-party could be compromised. Maybe there could be two wallet modes, one less secure mode that derives keys in a reversible way (when the chaincode is known) as in the current BIP32 design, and another more secure mode that derives keys via OWF? Maybe you should be able to use the different modes in different branches of your wallet file?
I would personally very much like to limit the number of variations we need to consider. You are right that there are security risks when a user can obtain a parent extended public key, and a child secret key, but I do not see a way to avoid this, except by dropping the ability to do public derivation. Right, the post above by jl2012 confused me. There seems to be an inherent contradiction between key homomorphism and leakage of the ancestor privkeys, in the sense that if some privkey k_i is compromised (and all the chaincodes and pubkeys of the wallet are public) then we have that I_L=HMAC(c_par, K_par||i) is known, and we can solve I_L * x = k_i (mod n) and obtain the privkey x=k_par Maybe another signatures scheme (instead of elliptic curves) could allow both key homomorphism and one-way derivation (in the sense that k_i wouldn't reveal k_par), I don't know. But we're not planning to move away from ECC anytime soon, certainly not just for deterministic wallets, so in practice it wouldn't matter. So far the only thing that I can think of is the straightforward option of allowing the user to encrypt the chaincodes (maybe with a "minor" password as I mentioned above) if he wishes to be less exposed to security risks. However, when client software does not expose a chain code ever, the whole sceme is effectively type-1, in the sens that it derives private data from private data (and knowing the public key gives you 0 information about the child key); it's a weirdly complicated randomization function, but it still is one.
I'm still not exactly sure what you mean by "client software does not expose a chain code ever". Suppose for example that the user stores his wallet.dat file on the cloud (e.g. dropbox), if the chaincodes aren't encrypted then they are exposed, no? So the user assumed that he's safe to store the wallet on the cloud because the privkeys are encrypted, but if a single privkey leaks somehow then all his other privkeys also leak, which isn't the case with the regular random-independent wallets. Regarding using addition instead of multiplication: we switched to multiplication at some point, but I can't remember why - the only thing it adds is removing the ability to compute I_L from a parent and a child pubkey, which doesn't seem to gain you anything.
With the additive variant, don't you get I_L*G from parent and a child pubkeys, rather than I_L itself? I'm still not sure what are the advantages of the multiplicative variant. Given the (supposedly) practical use cases that ErebusBat mentioned, I urge you to get more peer reviews regarding these security concerns where we might allow users to shoot themselves in the foot more easily, before you deploy BIP 32 in the official client. |
|
|
|
|
LR1c6QnbfcVzLnfcjhETfQn84wQFapY8w9
|
|
|
|
A serious solution is simply for several major stakeholders to publish signed endorsements and/or kills to blocks. Users can subscribe to them, and if a supermajority agrees to kill a block, the merchant at the very least can be configured to stop and go into safe mode.
I have thought of this long ago, now others might take the idea seriously. It was aggressively rejected in the past under the pretense it was too "centralized". I believe we need it to raise the bar on the risk of a 51% attack.
Your centralized protocol with few designated major stakeholders is indeed a terrible idea imho, for the reasons that we discussed in your thread. Fully decentralized proof-of-stake protocol can be sound, and can have several additional features that are very beneficial (in exchange for the additional complexity in the work that the nodes perform), but the security analysis should take into account bribe attacks etc., as discussed in the PoA thread. Peer review for the best protocol that we came up with so far would be very welcome, see here. |
|
|
|
I want to stress that BIP32 isn't final yet, so please don't release code that implements it.
If there is need to make changes still, I really want to avoid several different revisions in the wild.
I'll post test vectors in the BIP document as soon as I feel confident things won't change anymore.
Please reply in the end of the Deterministic wallets thread regarding the concerns that ErebusBat and I raised. |
|
|
|
|
Hello tacotime,
The main change to Litecoin that coblee, pooler, and I discussed is whether tweaking the scrypt params to make CPU mining more advantageous is a good idea, in order to decentralize the network further. You are of course welcome to share your thoughts on this here, especially given your memcoin thread etc.
Everyone is also welcome to discuss this kind of ideas at #litecoin-dev on freenode IRC chat.
|
|
|
|
|
Show Posts
