On Fri, Jan 03, 2014 at 07:21:17PM +0100, Jorge Timón wrote:
> On 1/3/14, Troy Benjegerdes wrote:
> > 'make' should check the hash.
>
> An attacker could replace that part of the makefile.
> Anyway, I think this is more oriented for compiled binaries, not for
> people downloading the sources. I a
On 1/3/14, Peter Todd wrote:
> On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote:
>> > You assume the value of a crypto-currency is equal to all miners, it's
>> > not.
>>
>> They should be able to sell the reward at similar prices in the market.
>> Attackers are losing the opportunity co
On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote:
> > You assume the value of a crypto-currency is equal to all miners, it's
> > not.
>
> They should be able to sell the reward at similar prices in the market.
> Attackers are losing the opportunity cost of mining the currency by
> attac
On Fri, Jan 03, 2014 at 09:23:20PM +0100, Adam Back wrote:
> Seems like you (Nadav) are the third person to reinvent this idea so far :)
Lol, fourth if you include me, although my case is rather embarassing as
I had re-read Bytecoin's original post recently and completely missed
the main point of
Seems like you (Nadav) are the third person to reinvent this idea so far :)
I wrote up some of the post-Bytecoin variants here:
https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530
The general limitation so far is its not SPV compatible, so the recipient
has to test each payment
On 1/1/14, Peter Todd wrote:
> On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote:
>> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
>> > that you are using merge-mining is a red-flag because without majority,
>> > or
>> > at least near-majority, hashing power an attacker can 51%
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi wrote:
> I had an idea for a payment scheme that uses key derivation, but instead of
> the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
> The payee publishes his master public key
> The payer generates a random "rec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is a standard mechanism for doing that called deterministic
signatures and is described in RFC 6979. It uses the private key and
the HMAC construction to generate a ECDSA k value.
On 01/03/2014 10:16 AM, Tier Nolan wrote:
> The random number tha
On 1/3/14, Troy Benjegerdes wrote:
> 'make' should check the hash.
An attacker could replace that part of the makefile.
Anyway, I think this is more oriented for compiled binaries, not for
people downloading the sources. I assume most of that people just use
git.
> The binary should check it's o
The random number that the buyer uses could be generated from a root key
too.
This would allow them to regenerate all random numbers that they used and
recreate their receipts. The master root would have to be stored on your
computer though.
The payment protocol is supposed to do something like
I had an idea for a payment scheme that uses key derivation, but instead of
the payee deriving the addresses, the payer would do it.
It would work like that:
1. The payee publishes his master public key
2. The payer generates a random "receipt number" (say, 25 random bytes)
3. The payer
On Fri, Jan 03, 2014 at 09:59:15AM +, Drak wrote:
> On 3 January 2014 05:45, Troy Benjegerdes wrote:
>
> > On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > > On Tue, Dec 31, 2013 at 5:39 AM, Drak wrote:
> > > > The NSA has the ability, right now to change every download o
You know if you want to make some form of investment, you might like make an
attempt to look them up on the internet, check the phone number in a phone
book or directory enquiries, look for references and reviews?
So it is with the hash of the binary you are about to trust with your
investment fun
On Fri, Jan 3, 2014 at 9:59 AM, Drak wrote:
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, auto
On 3 January 2014 05:45, Troy Benjegerdes wrote:
> On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > On Tue, Dec 31, 2013 at 5:39 AM, Drak wrote:
> > > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > > on the fly and the only cure is encryption
>
> Ideally it would be good to have two ports, one for the main net, and one
> for the test net. However, in light of conservation only one may be
> granted. The question as to whether traffic could be multiplexed over a
> single port may be raised.
>
I'm sure it would be *possible*, but testne
16 matches
Mail list logo
