These types of DBs are popular lately, for example, btcwallet now uses boltdb, while Monero uses LMDB. They're all kind of similar: full ACID semantics w/ MVCC, data stored on disk in B+ trees, async read/update with scheduling and transitory state patches for reads, multiple namespaces, nested buckets, etc. AFAIK, bitcore is moving towards adopting more DB agnostic architecture, so in the future you can plug and play whatever crazy DB type you want. |
|
|
|
|
You can use stealth addresses to send the payment to a specific vendor with a stealth address, providing the extra data to recover the private key on a separate channel e.g. email. You can encrypt information like post address to the recipient using the ECDH shared secret and a symmetric key cipher.
So basically, the receiver posts
[recipient_email_address]&[stealth_address]
Sender sends this information to the receiver's e-mail address:
[shared_secret] (for encryption and recovery of private key)
then this other encrypted information in the e-mail:
[requested_items]
[txid_for_payment]
[where_to_ship_to]
Sender uses the derived pubkeyhash as an address and sends their funds there on BTC mainnet, receiver gets e-mail, decrypts all relevant information, recovers privkey for the address yet sent to.
I've been meaning to implement this (and indeed I've started a bit), but I've had other things to work on lately.
|
|
|
|
|
David is core development team, but he's not really a programmer. He tends to handle PR and the like.
|
|
|
|
Also, am I right to say that the introduction of this new feature means that unlike other cryptocurrencies I would be able to pay for coffee and not to wait until my transaction is completed?
No, it just tells you if a tx with an output belonging to you is in the mempool or not. Previously you had to wait about 2 minutes for it to enter a block to see if it was there or not. It's not instant tx, it's more like "did any of the transactions I saw recently on the network have funds belonging to me". I think it was a Bitcoin core wallet feature from day one. |
|
|
|
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same. first 2 tx were 150 and 70 mixin. didn't help the others I tried to make identical ones at the same time. but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this. Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then. I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon. If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked. If I recall correctly, mixing will be at minimum 3. I think he said it, because he already stated that you should read MRL-0004, you shouldn't feel attacked though :-) I'm not. What I've meant is before I started this, I had no way of knowing about MRL-0004. You should put it on the OP. I think it's very important to know this. Ok, didn't go through the full document, if 3 is the way, I assume you did the math, 1 just didn't seem good. My suggestion will be then just: default 10 mixins, and no dust allowed. Hope that we'll see it fixed soon. And thanks for explaining this to me, and for your patience! We've known about this issue forever. https://bitcointalk.org/index.php?topic=789978.msg8904862#msg8904862This looks like aggressive posturing from a competitor, but as always, we'll have a solution out soon to fix this. |
|
|
|
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 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)
} |
|
|
|
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. |
|
|
|
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. |
|
|
|
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). |
|
|
|
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. |
|
|
|
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.  |
|
|
|
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. |
|
|
|
The linear interpolation of the Bitcoin subsidy function is already used in SpreadCoin (and others). 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;
} |
|
|
|
Thanks muchly Risto!  |
|
|
|
Eduffield has gone on a full out Ether(eum) binge |
|
|
|
|
Show Posts
