Bitcoin Forum
March 30, 2015, 04:15:38 PM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 163 »
1  Bitcoin / Development & Technical Discussion / Re: Go lang - Create a random Bitcoin address on: March 29, 2015, 04:08:39 PM
TacoTime,

Thank you!

How would I implement this in my current script?

I am not necessarily trying to vanity gen I am trying to create new addresses as quickly as possible and have them be as random as possible.

The reason I want to use Go is because I have seen a considerable difference in the speed.

C# is pretty slow, 2-3 keys a second, same with Python.

Go seems to be considerably faster, C would probably be the best.

Uh

Code:
for someCondition {
// Generate keypairs.
aKeypair, err := ecdsa.GenerateKey(btcec.S256(), crand.Reader)
if err != nil {
return err
}
pubkeyBtcec := btcec.PublicKey{aKeypair.PublicKey.Curve,
aKeypair.PublicKey.X,
aKeypair.PublicKey.Y}
keypairBtcec := btcec.PrivateKey{aKeypair.PublicKey, aKeypair.D}

// Create a map to json marshal
keypairMap := make(map[string]string)
keypairMap["pubkey"] = hex.EncodeToString(pubkeyBtcec.SerializeCompressed())
keypairMap["privkey"] = hex.EncodeToString(keypairBtcec.Serialize())

// Store the address in case anyone wants to use it for BTC
pkh, err := btcutil.NewAddressPubKey(pubkeyBtcec.SerializeCompressed(),
&btcnet.MainNetParams)
if err != nil {
return err
}
keypairMap["address"] = pkh.EncodeAddress()

b, err := json.Marshal(keypairMap)
if err != nil {
return err
}

fmt.Printf("%v\n", b)
}
2  Bitcoin / Development & Technical Discussion / Re: Go lang - Create a random Bitcoin address on: March 28, 2015, 07:04:19 PM
DON'T use your own cryptographic randomness source. DO use ecdsa.GenerateKey and crypto/rand.

https://github.com/monero-project/urs/blob/master/messagesign.go#L46-L82

Looping that would be naive because continual crand calls can be expensive... if you're trying to vanity gen, I would use BIP32 and just continually derive new addresses from a master seed until you found the one you want.

https://github.com/btcsuite/btcutil/tree/master/hdkeychain
https://github.com/btcsuite/btcwallet/tree/master/waddrmgr
3  Bitcoin / Development & Technical Discussion / Re: Unique Ring Signatures using secp256k1 keys on: March 21, 2015, 07:01:39 PM
I know this thread may be a bit outdated. But, I was wondering, is the mixin number that can be used, truly infinite? I know you can use a mixin of say 100,000 etc, but what about a mixin of truly incredible size, like 1,000,000,000(1billion)?

Well, andytoshi and adam3us I know were trying to see if there was a way to compress ring signatures so that they reference the entire utxo set. I'm not sure how far they got. For maximum size of ring signature members, you're mainly limited to the memory of the system you are working on. Both size of the ring signature and time to verify is O(n) with the current signature algorithms.

For those outside Monero, a "mixin" is a ring signature member not the actual signer.
4  Alternate cryptocurrencies / Altcoin Discussion / Re: What do you think about this POS algorithm? on: March 17, 2015, 02:38:38 AM
https://eprint.iacr.org/2014/452
5  Bitcoin / Bitcoin Discussion / Re: Cryptonote: More Bitcoin Than Bitcoin on: March 15, 2015, 12:36:38 AM
No, that's a separate, unrelated attack that still exists. Doublespend proof is referring to the niZKP component of the ring signatures.

See here:
https://lab.getmonero.org/pubs/MRL-0003.pdf
6  Bitcoin / Bitcoin Discussion / Re: Cryptonote: More Bitcoin Than Bitcoin on: March 15, 2015, 12:07:11 AM
I get the part about using one time addresses for transactions, so thats stealth addresses right. What about this (Double- spending Proof)? The blockchain anaylsis resistance also blows over me lol.

The issue with ring signatures is that you can't tell which input was spent, so you need a way to make sure that no one is double spending their input. Take for example outputs A,B,C, and ring signature R that spends from A OR B OR C. How can we make sure that the owner of A doesn't also get to spend B and C? The answer is by using a niZKP that demonstrates knowledge of the private key and gives a unique identifier per private key. This is called the key image.

So when A spends her funds, she produces both her signature saying it's A OR B OR C, and her unique key image. The owners of B and C then also have unique key images that allow them to spend their funds without identifying who they are to the network.
7  Bitcoin / Bitcoin Discussion / Re: Cryptonote: More Bitcoin Than Bitcoin on: March 14, 2015, 11:43:23 PM
It all seems great, but for some reason they are struggling to come up with a functional gui. AFAIK Monero still didn't got the gui going right?

We never messed around too much with a core GUI because there's so much as to do with the core code and core GUIs tend to become quickly antiquated (just look at Bitcoin-QT, which virtually no one uses anymore).
8  Alternate cryptocurrencies / Altcoin Discussion / Someone rewrote the Ethereum blog as poetry... on: March 14, 2015, 09:06:15 PM
...and I can't stop laughing.

https://blog.ethereum.org/author/vitalik-buterin/
https://archive.org/stream/EtherealVerses/Ethereal_Verses#page/n0/mode/2up
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: March 14, 2015, 05:49:24 PM
Where can i follow the progress of this release ?

i am waiting this version to add this coin on my website

Ty

Pull and build this branch: https://github.com/tewinget/bitmonero/tree/blockchain
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: March 13, 2015, 07:58:36 PM
This would certainly make decentralized exchanges easier to implement, would it not?

Trivial, even... you'd just port CounterParty or CoinPrism.

Then every blockchain simply becomes an exchange with varying liquidity and security. I think this might be the actual long term scalability solution.
11  Bitcoin / Development & Technical Discussion / Re: Continuous & piecewise linear block reward function with 21M limit unchanged on: March 13, 2015, 07:32:35 PM
Well you are never going to convince miners that they should take a voluntarily paycut to avoid 'disruptions' which may or may not happen in the future.  Any attempt to change the subsidy curve will realistically not happen.  Personally I think a lot of the 'end game' uncertainty in Bitcoin fees and security could be mitigated with a low but fixed inflation but that isn't going to happen either.  Just because any change is technically possible it doesn't mean it is realistically possible.

For completeness your code should indicate the starting point (similar to post #7) as I believe it returns a subsidy higher than 25 BTC for blocks in the existing era.  Since this will probably not happen for an existing chain I am curious what would be the simplest subsidy function that returns a 'smooth' curve from block 0.

Well, it's always there in Monero (~1% annual starting in year 10) if it's desirable.  Tongue
12  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: March 13, 2015, 07:15:54 PM
It's feasible, but for now I see side chains as not much more relevant than any other alt-coin exchange. The changes that would need to be implemented in BTC are not trivial nor have they even been presented as pull requests - aka it's vaporware, for now. The only way that side chains get implemented today are by federated servers which hold the private keys to all BTC 'locked' in multi-sig transactions in the main chain, representing value in the side chain.

While I do have a lot of respect for the Blockstream devs, it's just too soon to know if they'll be able to implement anything stronger than a mechanism requiring full trust in Blockstream Inc's federated servers. In this way, it's no different than Poloniex.

TLDR; Not a concern in the next few years.

There's also no way to keep Bitcoin out of our blockchain if we implement sidechains... We could transfer Bitcoin into the XMR sidechain as a token, then transfer it back to the BTC main chain (as long as we switch to a fast-to-verify hashing algorithm).

Conversely, there's no way to stop us from storing XMR on the BTC main chain as a token once sidechains are implemented too. In the future I think we'll see all cryptocurrency types traded in a distributed fashion on many different chains, with their tokens representing "equity" in the developing parties of the respective blockchains.
13  Bitcoin / Development & Technical Discussion / Re: Continuous & piecewise linear block reward function with 21M limit unchanged on: March 12, 2015, 07:26:08 PM
The linear interpolation of the Bitcoin subsidy function is already used in SpreadCoin (and others).

Code:
int64 GetBlockValue(int nHeight, int64 nFees)
{
    int64_t nSubsidy = 50 * COIN * 4 / 3;
    if (nHeight > (int)getFirstHardforkBlock())
        nSubsidy /= 10;

    // Subsidy is cut in half every g_RewardHalvingPeriod blocks which will occur approximately every 4 years.
    int halvings = nHeight / g_RewardHalvingPeriod;
    nSubsidy = (halvings >= 64)? 0 : (nSubsidy >> halvings);
    nSubsidy -= nSubsidy*(nHeight % g_RewardHalvingPeriod)/(2*g_RewardHalvingPeriod);

    return nSubsidy + nFees;
}

https://github.com/spreadcoin-project/spreadcoin/blob/b05777db815d633a76aba5ef55ecb85390a4df7e/src/main.cpp#L1340-L1352
14  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Speculation on: March 10, 2015, 08:09:20 PM
Thanks muchly Risto! Grin
15  Alternate cryptocurrencies / Altcoin Discussion / Re: [DRK] Darkcoin is NOT Anonymous? Possible Proof inside. on: March 09, 2015, 07:11:41 PM

Eduffield has gone on a full out Ether(eum) binge
16  Alternate cryptocurrencies / Altcoin Discussion / Research into ZeroCoin ongoing, and a multiparty non-trusted setup proposed on: March 08, 2015, 07:22:36 PM
ZRC is the "ultimate" case for privacy, in which all tx are totally obscured from the eyes of everyone else and it's impossible to tell how much money anyone else has (or even the system has). The only balances you can effectively know are your own. At the same time you can opt to use cryptography to prove ownership of funds, and where the funds are sent to.

The issue with ZRC was always that you needed a trusted party to setup the initial parameters set. If the trusted party doesn't destroy their keys after setup, then they can freely generate money of out the air and basically control the entire system.

The ZRC guys are now saying that they have found a solution and are implementing it:
Quote
However, I will address this caveat of this trusted setup. So what is this? Our zkSNARK trusted setup is for initial public parameters of the system. It only happens at genesis time. After that, no trust is required in the system ever. However, if the trusted setup is compromised, then an attacker can fake new coins and could totally trash your economy. An attacker cannot break your anonymity or steal your coins. That said, we weould like to get rid of trusted setup.

There is a paper by some of us which will be appearing soon (BCGTV15) where we propose a multi-party protocol for sampling the parameters. Efficient MPC protocol. If just one is honest, then parameters are going to be completely secure, meaning that an attacker needs to compromise every single one of the participants presumably on the different continents, to break the setup assumptions.
From the MIT Bitcoin expo:
http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark/

Of course, an unsolveable issue is when there's a bug that lets someone create a pile of coins that the creators didn't realize existed (as with Bitcoin), since no one can see how much money exists on the blockchain. If the same event happened with ZRC, that user would own 99% of the ZRC that would even come into existence.
17  Alternate cryptocurrencies / Altcoin Discussion / Re: [DRK] Darkcoin is NOT Anonymous? Possible Proof inside. on: March 08, 2015, 06:41:08 PM
Itís significant to this debate that Darkcoin had ring signatures on its roadmap and decided against implementing them (for now) because of adverse practical issues associated with their use - in particular the bloat problem.

DRK's solution is also O(n) in size and thus has the same relative amount of bloat, as I stated earlier in the thread... The only real reason I can see that DRK stuck to their CoinJoin model was because so much effort had already been made into writing a method of trying to decentralize CoinJoins, and because implementing ring signatures is a giant pain in the ass (you need to keep track of a whole separate database where you keep outputs of the same age in order of their incidence in the blockchain, for one).
18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: March 08, 2015, 05:47:12 PM
Two broader thoughts that have come up in discussions elsewhere.

1.) Luke-Jr stated the other day that he foresees ring signature functionality being implemented into Bitcoin in 2-3 years. My response was that even if that actually happens, it wouldn't have a mandatory mix-in level, limiting the anonymity capabilities that Bitcoin could offer with it. However, I've heard others state that you actually wouldn't need a mandatory mix-in level for it to impart "good enough" anonymity for it to kill interest in anything else. Regardless of whether this is true or not, it does sound like something that could steal some remaining thunder from the anonymity-niche coins, given that Bitcoin already has a huge market share.
2-3 years is optimistic for a blockchain that's been bickering over the size of blocks for years now. And yes, you do need minimum mixin levels to make the system secure, although there are ways of doing that within a Bitcoin softfork. However, this presents the problem of money going from non-anonymous addresses to anonymous addresses, which makes blacklisting/censorship really easy (CoinBase can see your output entered into a ring signature output and ban you). Blacklisting in Monero will be impossible.

This is exactly why gmaxwell and andytoshi proposed their Bitcoin sidechain, which uses BRS (Bytecoin Ring Signatures), much like Monero, but using Bitcoin. However, it's likely that the majority of Monero will already be distributed by the time this is released (if ever), and at that point channels to and from Bitcoin, along with much better liquidity, should already exist.

Quote
2.) I've had discussions recently with Bitcoin maximalists who claim that anything built on an altchain cannot succeed, because Bitcoin's blockchain will remain by far the longest chain, and any other altcoin based on a PoW altchain that *ever* begins to compete with Bitcoin for market share will cause interested parties to attack it with the magnitudes of greater resources that are behind the Bitcoin network. My thought on this was that given that Monero uses a different hashing algorithm than Bitcoin, the resources behind Bitcoin couldn't be redirected at Monero in any direct sense (especially if the predominant resources behind Bitcoin are ASICs). Now, that isn't to say that there couldn't *still* be enough incentive involved, if Monero ever became more popular, for Bitcoin supporters to attack Monero by devoting fresh resources/energy to attack it. Thoughts?
The Bitcoin shills are always going to say that nothing will be better than Bitcoin, because all their money is in Bitcoin.

Monero is different. Monero is digital cash, whereas Bitcoin is a hybrid equity-wiring service. Bitcoin has a fixed distribution amount and transparency amongst investors. Conversely, Monero inflationary, like real cash, with a small distribution period of approximately five years as basically an "ICO". It can be spent with privacy, like real cash. They're different entities, with a different promise.
19  Alternate cryptocurrencies / Altcoin Discussion / Re: [DRK] Darkcoin is NOT Anonymous? Possible Proof inside. on: March 08, 2015, 02:24:25 AM
Well, I haven't really gone through the entire thread but I don't think the DRK CoinJoin is entirely unsound from the perspective of being a centralized CoinJoin.

The theory is basically, you have n many outputs (O_n) of denomination size D. For simplicity, for any O_n there is an owner Z_n.

Z_n sends her output O_n to a masternode (MN) along with a new receiving address A_n. The MN shuffles these O_n as inputs and makes shuffled outputs to A_n in a single tx. The tx is then signed by all Z_n. The MN submits the tx to the network and the outputs are indistinguishable to everyone except the MN. Well, they're slightly known to the participants too, because they know which address and input is theirs.

It suffers from some of the same flaws as ring signatures (I'm not going to go over that, we've already published on them). But at the same time, ring signatures (a) don't require a MN (centralized) to do mixing because you can use any previous outpoint and (b) are somewhat more expensive space wise (but not really; see below) and (c) the MNs know 100% the outputs owned by their participants, who obviously have to connect to them somehow over TCP/IP. The last point is a big deal in terms of privacy, and even with Tor you can have timing correlation attacks.

The size of the ring signature is O(n), but then again, so is sequential DarkCoin mixing, per mix tx. The cost per mix for DRK is that of the signed input and output for the recipient, and the obfuscational security of a single tx is also O(n). For the latter I mean number of participants in terms of inputs/outputs... obviously a single participant is useless, and two participants is nearly useless. So, the DRK method still introduces O(n) bloat. It just load balances it differently.

The fact that the MNs are the centralized authority in the CoinJoin and now in network consensus (as of instant tx, since the MN decide which chain is valid by which tx is allowed to be in it) is more of an issue, along with providing correct incentives. Long term most of the rewards go to the MNs who I would guess will, over time, become progressively more pernicious in their activities. Another issue is legal ones for potential people running MNs, as they're effectively laundering money on behalf of the participants and directly benefiting from doing so monetarily.
20  Bitcoin / Bitcoin Discussion / Re: Cryptonote: More Bitcoin Than Bitcoin on: March 07, 2015, 10:49:01 PM
1. DSA is out of my area of expertise so I'll let others such as tacotime address it.

EdDSA is a 64-bit architecture optimized Schnorr signature over a birationally equivalent curve of Curve25519. It was designed by renown cryptographer Daniel J. Bernstein. Curve25519 has been widely used as of recently in cryptography software.

DJB wrote about the design of the curve and EdDSA here: http://blog.cr.yp.to/20140323-ecdsa.html
He also made a large comparison table of features here: http://safecurves.cr.yp.to/
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 163 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!