More somewhat improved crypto stuff...
On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote:
>I suggested fixed size committed coin spends [...]
>
>(blind-sender, auth-tag, encrypted-tx-commit)
>
>(pub key P = xG, G = base point)
>
> blind-sender = cP (public key EC multiplied by consta
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote:
>[committed coins] depending on how its done, at most conceals the
>transactions from people who aren't a party to them... though as time goes
>on eventually everyone becomes a party to a sufficiently old coin, and
>avoiding publicat
Not only does the size of the proof grow endlessly as the coin is
passed around, the size of the UTXO set grows endlessly as more and
more of the already spent coins cannot be proven to have been spent
because the proofs are passed out-of-band. I never said the idea was
good, just interesting :)
T
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn wrote:
> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
Zerocoin conceals the connection from everyone forever, assuming the
underlying trapdoor problem is computational infeasible, but at great
cost.
Adamcoin, depending on how its
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
I'm not really convinced miner cartels that try to exclude transactions are
likely to be a big deal, but such schemes could I suppose be kept in a back
pocket in case one day I'm proven wrong.
On Wed, May 15, 2013 at 6:39 PM, Gr
On Wed, May 15, 2013 at 6:24 PM, Gavin wrote:
> Busy with pre-conference stuff, not following details of this conversation...
>
> ... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking
> about a year or so ago.
Sort of, but in a guy fawkes signature you use the commitment to h
Busy with pre-conference stuff, not following details of this conversation...
... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking about
a year or so ago.
--
AlienVault Unified Security Management (US
btw I posted some of this thread on the dev forum:
https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994
A related idea is occuring to me that maybe these committed transactions
could actually as a side effect make bitcoin scale slightly better by
reducing the p2p flood filled tran
On 05/15/2013 12:21 PM, Adam Back wrote:
> On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>> If the commitment is opaque at the time of inclusion in the block then
>> I will create multiple commitments and then after revealing the
>> commitment and spend to you I will reveal
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>If the commitment is opaque at the time of inclusion in the block then
>I will create multiple commitments and then after revealing the
>commitment and spend to you I will reveal the earlier commitment which
>commits the coins to
I can't see this working, if 51% of the mining power doesn't like your
coins, when you create the commitment they will reject it.
If the commitment is opaque at the time of inclusion in the block then
I will create multiple commitments and then after revealing the
commitment and spend to you I will
On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>Protocols aren't set in stone - any attacker that controls enough
>hashing power to pose a 51% attack can simply demand that you use a
>Bitcoin client modified [to facilitate evaluation of his policy]
Protocol voting is a vote per user p
On Wed, May 15, 2013 at 12:25:09PM +0200, Adam Back wrote:
Protocols aren't set in stone - any attacker that controls enough
hashing power to pose a 51% attack can simply demand that you use a
Bitcoin client modified to provide the attack with the full transactions
from the beginning. Any blocks c
So in a previous mail I described a simple, extremely efficient and easy to
implement symmetric key commitment that is unlinkable until reveal time (at
bottom). I think this can help improve the byzantine generals problem, that
bitcoin only defends to simple majority (with one vote per CPU power),
14 matches
Mail list logo
