sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
<Taek>
I'm not entirely sure if this has been discussed before
<Taek>
but I was thinking that one tool to potential stabilize the price would be to adjust the coinbase later
<Taek>
err
<Taek>
basically right now if the hashrate spikes, you get some number of blocks that happen quicker
<Taek>
during this time there's more inflation
<Taek>
generally, when the hashrate spikes its due to a price increase. But as a confounding factor it can also be due to hardware improvements
<Taek>
the burst of inflation helps to offset the price increase
<Taek>
similarly, price drops can be followed by hashrate drops
<Taek>
the supply for some time decreases though, which can help to offset the decreasing price
<Taek>
in practice the hashrate basically only goes up
<Taek>
anyway the general idea is that you exacerbate this effect a bit, so that instead of the inflation correcting within 2 weeks you have it correct over the course of like 3 months or 6 months
<Taek>
(you still adjust the difficulty right away)
<Taek>
(you just also adjust the coinbase amount so that the inflation is temporarily conserved)
chjj has quit [Ping timeout: 258 seconds]
<Taek>
but again, not really useful today because the hardware improvements are too much of a confounding factor, hashrate really cannot be used as a proxy for coin price
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<Taek>
I would expect the improvements to level off at some point though, just as clock rate improvements eventually leveled off
chjj has joined #bitcoin-wizards
Starduster has quit []
Newyorkadam has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
<fluffypony>
if anyone's interested, we're designing a scheme for Monero sub-addresses (almost like HD wallets) so that users don't have to use their main address with ShapeShift, for eg., to avoid third-party linkage
<gmaxwell>
fluffypony: have you considered an address type for "precomputed DH" e.g. a single use address where you do the DH math and then give the address to someone to pay?
<gmaxwell>
this would avoid inflating the scanning costs.
<fluffypony>
as in the recipient precomputes the DHKE shared secret and just gives that to the sender?
<gmaxwell>
yep.
<gmaxwell>
single-use address.
<fluffypony>
I have no idea how nobody's thought of that
<fluffypony>
that makes total sense
* fluffypony
feels noobish now
<gmaxwell>
I've mentioned it here before in the context of stealth addresses and the C**nB*ase problem. (steal address gives the person who would block you even more tracing ability).
<gmaxwell>
For monero it's even better because you already forbid address reuse (right?)...
<gmaxwell>
er s/steal/stealth/
chjj has joined #bitcoin-wizards
<fluffypony>
yes
<gmaxwell>
I don't think it replaces the ability to have seperate keys in a wallet.. you might not want to use single use addresses for everything.
<fluffypony>
agreed - a regular address can just be given out
<fluffypony>
a single-use address would have this added step (paste the sender's address in, compute, then send this to the sender)
<fluffypony>
which is counter-intuitive to people more familiar with the Bitcoin, PayPal, etc. way of doing things
<gmaxwell>
you can actually generate the whole thing, I think. e.g. just pick a random number, and tell it to the sender.
<gmaxwell>
I'm currently fuzzy on the monero schemes. but basically you compute a random number, the shared secret, give the sender the kG and the output address they should pay.
<gmaxwell>
and they can stuff it in their transaction and just sign it.
se3000 has quit [Ping timeout: 255 seconds]
EvilHero_ is now known as Datalova
<gmaxwell>
if monero doesn't already guarentee that you can't pay to the same output pubkey twice then an extra check will be needed for safty.
<fluffypony>
"Alice generates a random r ∈ [1,l−1] and computes a one-time public key P = Hs(rA)G+B.
<fluffypony>
Alice uses P as a destination key for the output and also packs value R = rG (as a part of the Diffie-Hellman exchange) somewhere into the transaction."
<fluffypony>
A and B are the view and spend keys
<fluffypony>
and G is a base point
<gmaxwell>
right so payee would do all of that and send R and P in the address.
<othe>
[02:56:05] <gmaxwell>if monero doesn't already guarentee that you can't pay to the same output pubkey twice then an extra check will be needed for safty. --- it doesnt
<fluffypony>
yeah, but then you can't prevent re-use
<gmaxwell>
Then payer would check to see if P has been paid to in the past, and reject if it has.. (otherwise coins get burned)
<gmaxwell>
if the user happens to give the same address to two payers at the same time, then coins get burned. :( I would suggest relay policy at least to reduce that risk.
<gmaxwell>
E.g. don't let two outputs to the same P ... at least 'recently'.
<gmaxwell>
since they'll have the same image thus only one will be spendable.
* fluffypony
mulls over in his mind
<gmaxwell>
to be clear, I propose payer check the chain for reuse, and reject the chain. And I propose nodes and esp miners watch for recent reuse and reject to reduce the risk that the user concurrenty gives the same address to two payers. You could also fork it out but it's an increase in validation cost. (an extra database lookup)
<gmaxwell>
er and reject the ADDRESS! not chain.
dnaleor has quit [Ping timeout: 240 seconds]
<gmaxwell>
I expect that for these use cases the use is single, adding a new chain to scan forever to each single use address sucks.
<fluffypony>
yeah, so maybe increased scanning overhead is net-better than that
<gmaxwell>
hm? I am saying that if you create a new view/spend keypair for each single use application, you increase scanning cost O(N) which sucks; instead you can precompute and remain O(1) for scanning, but take on costs/risks related to reuse.
<gmaxwell>
you could mitigate reuse risk with a 2-phase protocol. (address bakes in some kind of payer nonce) but that breaks workflow. Or by hardening wallets and miners against double payment.
<gmaxwell>
Or even by softforking out doublepayment (validation cost increase)
<gmaxwell>
Or semi-softforking it out, e.g. "no duplicate of an address payed to in the last n blocks"
<gmaxwell>
FWIW, I've contemplated that for bitcoin. e.g. a pubkey type defined to be single payment which is deduplicated over a limited horizon by consensus and over forever by policy.