On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Timón wrote:
Here is a solution to the problem of having 0 confirmation
transactions
FWIW I'm running an experiment right now to detect how easy it is to
doublespend 0-conf transactions I need to collect more data, but initial
results indicate
On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:
... proposing the mechanism be used to claw back mining income from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware.
I think this would not be doable in
On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time
to be some stable linear relationships with the time that it
takes to reach different quartiles. Has anyone done this? I have used some
empirical data that I am happy to share but ideally I would like analytical
solutions.
Following Peter Todd, I also find the concerning result that propagation
On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote:
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
I have some questions:
1. How can we work towards solving the double-spending problem?
We have this awesome technology that solves the double-spending
You may have seen my reddit post of the same title a few days ago:
http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/
I've done some more experiments since, with good results. For instance
here's a real-world double-spend of the gambling service
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
But we
have
to be realistic. Desktop tower machines that are always on are dying
and
will not be coming back. Not a single person I know uses them anymore,
they
have been wiped out in favour of laptops. This is why, given the tiny
size
of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 April 2014 05:17:28 GMT-04:00, Mike Hearn m...@plan99.net wrote:
I find it is odd that we who hold the key to instant machine to
machine
micro payments do not use it to incentivise committing resources to
the
network.
It's not a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 April 2014 06:44:32 GMT-04:00, Tamas Blummer ta...@bitsofproof.com
wrote:
Thanks, Peter and you convinced me. I run away with a thought.
It’d be great to find a spot to deploy payment channels, but I agree
this is not it.
No problem!
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 April 2014 07:32:44 GMT-04:00, Pieter Wuille pieter.wui...@gmail.com
wrote:
There were earlier discussions.
The two ideas were either using one or a few service bits to indicate
availability of blocks, or to extend addr messages with some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 April 2014 07:45:16 GMT-04:00, Mike Hearn m...@plan99.net wrote:
Oh yeah, credit goes to Mike Hearn for the payment channels, and if
I'm
correct, for the hub concept as well.
Actually, the design is from Satoshi and Matt did most of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 April 2014 07:50:55 GMT-04:00, Gregory Maxwell gmaxw...@gmail.com wrote:
(Just be glad I'm not suggesting coding the entire blockchain with an
error correcting code so that it doesn't matter which subset you're
holding)
I forgot to ask last
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 April 2014 12:27:13 GMT-04:00, Tamas Blummer ta...@bitsofproof.com wrote:
A border router that is not able to serve blocks is still protecting
consensus rules, that SPVs do not.
If the network would only consist of SPV nodes only then e.g. a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 9 April 2014 13:50:03 GMT-04:00, Tamas Blummer ta...@bitsofproof.com wrote:
Block header has to be available in SPV and also in an UTXO only
storing core node, so why not serve it if bandwith allows.
Serving any additional information like
On Sun, Apr 06, 2014 at 09:35:20AM +0200, Maciej Trebacz wrote:
So, OP_RETURN is here and there is no coming back. So if we have it, it
would be nice to actually make use of it in a good way. I would like to
write a process BIP with a proposal for standardizing OP_RETURN
transactions for
On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote:
Hi all,
I understand this is a controversial proposal, but bear with me please.
I believe we cannot accept the current subsidy schedule anymore, so I
wrote a small draft BIP with a proposal to turn Bitcoin into a
On Fri, Mar 28, 2014 at 12:07:04PM +0100, Mike Hearn wrote:
Though I am loathe to go back and redesign this part of BIP 70 so soon
after we shipped v1, it seems to me like the refund feature may be hard to
implement on phones if there's no time limit for when you can receive a
refund.
On Mon, Mar 31, 2014 at 12:21:03PM +0200, vv01f wrote:
Some users on bitcointalk[0] would like to have their vanity addresses
available for others easily to find and verify the ownership over a kind
of WoT. Right now they sign their own addresses and quote them in the
forums.
As I pointed out
On Sat, Mar 22, 2014 at 12:43:34PM -0700, Mark Friedenbach wrote:
Btw, any chance we could get a summary description of tree-chains
posted to bitcoin-development?
Sure:
Introduction
Bitcoin doesn't scale. There's a lot of issues at hand here, but the
most fundemental of them is
On Tue, Mar 25, 2014 at 08:28:51AM -0400, Peter Todd wrote:
On Sat, Mar 22, 2014 at 12:43:34PM -0700, Mark Friedenbach wrote:
Btw, any chance we could get a summary description of tree-chains
posted to bitcoin-development?
Sure:
Introduction
BTW for those whose email
On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote:
Bitcoin doesn't scale. There's a lot of issues at hand here, but the
most fundemental of them is that to create a block you need to update
the state
. Puzzled, I asked why, maybe the process isn't clear or we didn't
talk
about what they were interested in? No, it's because in that executives
words They see how Peter Todd shoots people down in flames and want
nothing to do with that.
Peter, you were named explicitly as the source of the problem. Your
on this list. Btw I
also
met people who were making fun about Peter's reactions on bitcoin-dev.
slush
On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner etothe...@gmail.com
wrote:
I would echo the need for some kind of moderation.
I believe Peter Todd is an extremely intelligent individual, who
Introduction
In the wake of the Mt. Gox debacle merkle-sum-trees for
proof-of-reserve(1) have been getting attention again. A serious
objection to using them is exchange privacy as the merkle-sum-tree
inherently reveals the sum total of all deposits held by a given
service. A second,
There's been a lot of recent hoopla over proof-of-publication, with the
OP_RETURN data length getting reduced to a rather useless 40 bytes at
the last minute prior to the 0.9 release. Secondly I noticed a
overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
into account, making
On Sat, Mar 22, 2014 at 06:03:03PM +0100, Mike Hearn wrote:
In case you didn't see this yet,
http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
If you're using PGP to verify Bitcoin downloads, it's very important that
you check you are using the right key. Someone
On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
There's been a lot of recent hoopla over proof-of-publication, with the
OP_RETURN data length getting reduced to a rather useless 40 bytes at
the last minute prior
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote:
On 3/22/14, Peter Todd p...@petertodd.org wrote:
There's been a lot of recent hoopla over proof-of-publication, with the
OP_RETURN data length getting reduced to a rather useless 40 bytes at
the last minute prior to the 0.9
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I noticed that the ngccbase Colored Coin client(1) added a
python-bitcoinlib dependency, specifically my fork. In addition there is
also now a rudementary python-bitcoinlib package in archlinux.
So with that in mind I'm releasing v0.1, perhaps
On Sat, Mar 15, 2014 at 05:12:42PM +, Drak wrote:
Would it make sense to pull that stuff in and add Peter with commit access
since your repo is top of the fork tree.
I've noticed it looks like people actually using my 'pythonize' code
have been linking directly to my tree in things like
On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd p...@petertodd.org wrote:
That's nice, but I wrote my advice to show people how even if they don't
know any crypto beyond what the black boxes do - the absolute minimum
you need
On Wed, Mar 12, 2014 at 05:14:25PM +0100, Mike Hearn wrote:
Can this be calculated in advance knowing the initial transaction size and
the number of signatures required?
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get
On Tue, Mar 11, 2014 at 10:13:48AM -0400, Jeff Garzik wrote:
Sure, but I don't see wallets being able to _assume_ _remote_ parties
have an HD wallet for a long, long time. Interoperability common
sense implies the environment will be heterogenous, perhaps forever,
invalidating
On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:
On 3/5/2014 7:49 AM, Mike Hearn wrote:
A new practical technique has been published that can recover
secp256k1 private keys after observing OpenSSL calculate as little
as 200 signatures:
How can we patch this issue?
If you're following
On Wed, Mar 05, 2014 at 11:51:25AM -0800, Gregory Maxwell wrote:
On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd p...@petertodd.org wrote:
If you're following good practices you're not particularly vulneable to
it, if at all, even if you make use of shared hosting. First of all you
shouldn't
On Sun, Mar 02, 2014 at 03:10:09PM -0500, Tom Geller wrote:
Hey, folks. Sorry if this is documented somewhere -- if so, just point me at
it. I couldn't find it, though.
I'm a (non-developer) writer with experience in open-source communities, and
I'd like to contribute with
On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote:
If I understand correctly, the risk here is this would open a
historically large discrepancy between MIN_RELAY and the expected
minimum fee to actually obtain block inclusion. I don't know if
that's true, but I think that's what
On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Timón wrote:
First of all, sorry for the delayed answer.
On 2/10/14, Peter Todd p...@petertodd.org wrote:
Got this:
[...]
Thank you, I knew this wasn't new for us but I doubted we had written
it anywhere.
As said in those mails, being only
On Tue, Feb 25, 2014 at 06:25:18PM +0530, Mike Hearn wrote:
Given that the fee drop puts fees in real (i.e. dollar) terms back to
where they were some months ago, it seems odd to claim this is creating
vulnerabilities that didn't exist in the previous version. The cost of an
attack would be
On Tue, Feb 25, 2014 at 10:25:58PM +0530, Mike Hearn wrote:
Well, I've done my responsible disclosure, and I've got better things to
do than argue with wishful thinking.
There are two possibilities.
One is that the value of transactions with the new lower fee is outweighed
by increased
So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop doesn't open up an obvious
low-risk DDoS exploit right? As we all know, the network bandwidth
DoS attack mitigation strategy relies on transactions we accept to
mempools getting
On Fri, Feb 21, 2014 at 04:11:06PM +0530, Mike Hearn wrote:
On Fri, Feb 21, 2014 at 12:20 PM, Jeff Garzik jgar...@bitpay.com wrote:
RE doesn't buy you anything Today, when unlocked, plaintext
private keys reside in the same address space as the blockchain engine
(BCE). Process
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
parts of transactions)
On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote:
The payment protocol is also the perfect opportunity to implement merge
avoidance to increase customer and merchant privacy. The merchant can
simply deliver multiple outputs in the payment details, say 10 or so,
and the customer
On Wed, Feb 12, 2014 at 08:34:48AM -0800, Dan Carter wrote:
I'm not sure how well this would work.
Sure it would provide honest historical pricing, but those who wait for
publication confirmation may be at a disadvantage -- to get the best
deal possible Bob would connect to as many nodes
On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote:
If you've got any ideas for a better forum, let me know.
Your political conversations would be welcome at unsys...@lists.dyne.org
See you there.
--
'peter'[:-1]@petertodd.org
On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote:
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
that allows colored coins and similar embedded consensus system assets
to be securely transferred
On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote:
Hi guys,
Please check this thread
https://bitcointalk.org/index.php?topic=458608.0for a possible attack
scenario.
Already mailed Gavin, Mike Hearn and Adam about this :
See if it makes sense.
That's basically what appears to
The Problem
===
We have an embedded consensus system and we want to be able to upgrade
it with new rules. There inevitably will be a transition period where
some users use clients that interpret the new rules, while others only
interpret the old rules. Since we only rely on the host
the underlying change desired in the consensus state
atomically.
1) Alex Mizrahi, color kernel design considerations, Jan 7th 2014,
Colored coins (BitcoinX) mailing list,
https://groups.google.com/d/msg/bitcoinx/pON4XCIBeV4/IvzwkU8Vch0J
2) Peter Todd, [Bitcoin-development] Disentangling Crypto-Coin
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts a central authority and gives developers too much power.
Please
On Sun, Feb 09, 2014 at 12:11:32PM -0600, Troy Benjegerdes wrote:
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
that allows colored coins and similar embedded consensus system assets
to be securely transferred to another party in exchange for Bitcoins
atomically. In summary
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed
Thanks for the great response! I had about a dozen or so people contact
me with solutions for one or more questions, and even a anonymous
donation of 75mBTC to cover the rewards.
I'll start with my summaries of those solutions:
On Tue, Feb 04, 2014 at 08:03:13AM -0500, Peter Todd wrote:
On Tue
On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
Hello,
I'm pleased to announce the release of bitcoinj 0.11, a library for writing
Bitcoin applications that run on the JVM. BitcoinJ is widely used across the
Bitcoin community; some users include Bitcoin Wallet for Android,
/288f3c17626974de7eaef4f1c9b5cd93eecf40f6
Why is that a bad idea?
Bonus question: What was I smoking? (hint: where do I live?)
On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd p...@petertodd.org wrote:
On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
Hello,
I'm pleased to announce the release of bitcoinj 0.11
On Tue, Feb 04, 2014 at 09:43:31AM -0500, Jeff Garzik wrote:
On Tue, Feb 4, 2014 at 8:17 AM, Peter Todd p...@petertodd.org wrote:
Bonus question: What was I smoking? (hint: where do I live?)
Cryptographers smoke... hash, right?
(couldn't resist)
groan
I think we have a winner; as you
On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
Because it's trivial to create collisions! You can choose exactly what
output you want. That's why XOR is a very bad digest scheme.
You're close, but not quite.
So, imagine you have a merkle tree, and you're trying to timestamp some
On Sat, Jan 25, 2014 at 05:19:01PM +0100, Adam Back wrote:
[quote author=adam3us link=topic=431756.msg4729682#msg4729682
date=1390660452]
So have been talking with Greg Maxwell, Peter Todd, Jeremy Spillman,
Mike Hearn, Bytecoin and others about reusable addresses.
There is a summary
On Sun, Feb 02, 2014 at 01:16:20AM -0800, Jeremy Spilman wrote:
Consequently you can now securely and very network/space efficiently
securely delegate searching a block by computing the private key for the
IBE pub key that any sender would use for that block, and sending it as
a query to a
is not - as an example
archive.org didn't have that URL until I manually told it to archive it.
So I'm taking the liberty of reposting your two posts there below:
[quote author=adam3us link=topic=431756.msg4729682#msg4729682
date=1390660452]
So have been talking with Greg Maxwell, Peter Todd, Jeremy
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
inability to
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every
On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
Let's say the payee's reusable address is 'version prefix Q1 Q2
...', where prefix is 2 bytes. Without any length indicator. What's the
payer going to put on the blockchain? How would they know what the 'rest
of the space'
On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote:
brittleness. The real world experience is that users, or to be exact
wallet authors, turn down SPV privacy parameters until bloom filters
have almost no privacy in exchange for little bandwidth usage.
That's not fundamental
On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
Ignoring prefixes the cost for each reusable address is only a small
percentage of the full node cost (rational: each transaction has one
or more ECDSA signatures, and the derivation is no more expensive), so
I would only
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote:
Hi all,
during recent months we've reconsidered all comments which we received
from the community about our BIP39 proposal and we tried to meet all
requirements
On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
I must say, this shed is mighty fine looking. It'd be a great place to
store our bikes. But, what colour should we paint it?
I think we should paint it this colour:
They had uncovered what seemed to be the side of a large coloured
Finally seeing a more complex script-use-case being implemented:
http://www.coindesk.com/reality-keys-bitcoins-third-party-guarantor-contracts/
Enter Reality Keys, a new service by Tokyo-based startup Social
Minds due for public launch on 20th January. Reality Keys provides
On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
Might I propose reusable address.
I think that describes it best to any non-programmer, and even more
so encourages wallets to present options as 'one time use' vs
'reusable'.
It definitely packs a marketing punch which could
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
It's a given this will be implemented for Payment Protocol. The question
is whether it's also usable outside of PP.
I think what stealth addresses is showing is that the concept of an
address being instructions on how to generate
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH. The reason to use two is that it makes delegating
detection
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
Maybe you are saying:
byte[] S = EC.DH(e, Q2);
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
But the payment would have (q2New - q1New) == (Q2 - Q1), so I
On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
Uh while I'm responding again, what I'd discussed with Peter Todd in
IRC used two EC points in the stealth address. One for the payment and
one for the ECDH. The reason to use two is that it makes delegating
detection possible
On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
I don't know if stealth addresses are the best solution to address
this use case, but AFAIK the only current solution to this use case is
to store a long-lived Bitcoin address in the addresss book.
roy
Fair enough. I
On Tue, Jan 07, 2014 at 10:34:46PM -0800, Jeremy Spilman wrote:
2) Common prefixes: Generate addresses such that for a given wallet they
all share a fixed prefix. The length of that prefix determines the
anonymity set and associated privacy/bandwidth tradeoff, which
remainds a fixed
On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote:
On 1/6/14, Peter Todd p...@petertodd.org wrote:
On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
It's not meant to prove anything - the proof-of-sacrificed-bitcoins
mentioned(*) in it is secure only if Bitcoin itself
On Fri, Jan 10, 2014 at 06:11:28AM -0500, Peter Todd wrote:
Fair enough.
Do you see any case where an independently pow validated altcoin is
more secure than a merged mined one?
Situations where decentralized consensus systems are competing for
market share in some domain certainely
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote:
On 10 January 2014 10:20, Peter Todd p...@petertodd.org wrote:
Oh, sorry, I forgot to mention it in my first write-up but you can
easily make stealth addresses include a second pubkey for the purpose of
the communication that either
On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote:
On 1/10/14, Peter Todd p...@petertodd.org wrote:
Situations where decentralized consensus systems are competing for
market share in some domain certainely apply. For instance if I were to
create a competitor to Namecoin, perhaps
) Gregory Maxwell, Dark Wallet Certification discussions, also
http://snowdenandthefuture.info/PartIII.html
3) Peter Todd, [Bitcoin-development] Privacy and blockchain data,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
4) Bitcoin Wiki, Maximum transaction
On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
Hello and happy new year to this mailing list!
Thank you Mark for the incredible work you've been doing on this.
I am following this very closely, because it is of primary importance
for Electrum.
I have written a
* Summary
CoinJoin, CoinSwap and similar technologies improve your privacy by
making sure information about what coins you own doesn't make it into
the blockchain, but syncing your wallet is a privacy risk in itself and
can easily leak that same info. Here's an overview of that risk, how to
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
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
attacking
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% attack your
altcoin at negligible cost
On Wed, Jan 01, 2014 at 05:09:27AM +, Luke-Jr wrote:
You assume the value of a crypto-currency is equal to all miners, it's
not.
Suppose I create a merge-mined Zerocoin implementation with a 1:1
BTC/ZTC exchange rate enforced by the software. You can't argue this is
a scamcoin;
On Sun, Dec 29, 2013 at 11:53:19AM -0700, Evan Duffield wrote:
Hello,
We’re a startup looking for 1 or 2 really good C++ programmer that is
familiar with the bitcoin internals to help with a for-profit startup.
We will be able to provide more information about the project after signing
a
On Tue, Dec 24, 2013 at 12:52:46AM -0800, Jeremy Spilman wrote:
Some really nice efforts out there to map and analyze the bitcoin P2P
network.
The current protocol apparently recommends returning up to 2500 addresses
from 'getaddr'. I'm not sure how much clients are expected to probe
On Fri, Dec 20, 2013 at 03:10:50AM -0800, Mark Friedenbach wrote:
On 12/20/2013 02:48 AM, Peter Todd wrote:
On Thu, Dec 19, 2013 at 05:47:52PM -0800, Mark Friedenbach wrote:
This BIP describes the authenticated prefix tree and its many
variations in terms of its serialized representation
amount of time.
1) Gregory Maxwell, [Bitcoin-development] To prevent arbitrary data
storage in txouts — The Ultimate Solution,
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01987.html
2) Peter Todd, Re: MasterCoin: New Protocol Layer Starting From “The
Exodus
Here's my draft. I don't claim this to be official, but I think this
should represent the consensus we've come to at the DarkWallet
Hackathon; I'm writing it up as an email in part to preserve a record of
that consensus.
* General Principles
We believe in decentralization, user-defined privacy,
On Thu, Dec 19, 2013 at 04:04:17PM -, Amir Taaki wrote:
Looks like for this to actually go to the email lists they need to be in
the To: field.
About signing each commit, Linus advises against it:
http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
Btw, there's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mike Hearn m...@plan99.net wrote:
I think this US/other cultural issue is complicating things more than
we
appreciate.
I am trying to imagine in my head how all this will work and what it
will
look like with allow_fee, and I just can't see it.
On Wed, Dec 04, 2013 at 12:09:42PM +0100, Mike Hearn wrote:
Please don't try and drag this thread off topic. What I said is factually
correct. If you want to (again) try and convince people things should work
differently, start another thread for that.
replace-by-fee is no less speculative
On Wed, Dec 04, 2013 at 02:48:08PM +0100, Mike Hearn wrote:
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd p...@petertodd.org wrote:
replace-by-fee is no less speculative than your original proposals;
you're also trying to convince people that things should work
differently re: fees
On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote:
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net wrote:
PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
added easily, but we also need to launch the existing feature set.
Lets bang out a
201 - 300 of 455 matches
Mail list logo
