On Fri, Sep 30, 2011 at 1:21 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Accepting this does not preclude adding more 'standard' transaction
types in the future.
I think 2 of 3 is a _far_ more useful example than (a or b), it is
the prototype for a normal escrow transaction., and still
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote:
You give the hash to whoever is paying you, and store the hash --
script mapping when you do that (assuming you're not using a
deterministic wallet; if you are, you probably just increment a
counter in the wallet).
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote:
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell tyrell.el...@gmail.com wrote:
On 2012-01-02 05:31:19 -0800, Christian Decker said:
Later full blocks would be required to detect usable inputs for future
outgoing transactions.
Er, yes, this is what I meant; I guess I should have been more
On Mon, Jan 16, 2012 at 9:37 PM, Kyle Henderson k...@old.school.nz wrote:
For those that believe one particularly noisy country in the North America
region with a policy called SOPA or PIPA directly affects Bitcoin - can you
point out precisely where it does so?
In addition to the concerns
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki zgen...@yahoo.com wrote:
How could you have a 70 byte long address without a P2SH scheme? Is this a
mistake?
... No it's not a mistake. P2SH _prevents_ needing long addresses.
Lets unpack the acronym pay to script _hash_. Hashes only need to
be
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I've also been wondering if it is time to remove the IRC bootstrapping
mechanism; it would remove a fair bit of code and we'd stop getting
reports that various ISPs tag bitcoin as malware. When testing the
list of
On Tue, Jan 31, 2012 at 9:33 AM, slush sl...@centrum.cz wrote:
excuse me if it was already discussed, but maybe using satoshis instead of
decimal bitcoin would be better choice? We all know about pains with proper
handling decimal numbers across of all implementations - and it's not only
about
On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins andypark...@gmail.com wrote:
Hello,
Gulp. Am a little nervous about wading into this swamp. However, it seems
to me that the debate has veered into the personal and away from the
I think you've been deceived by people who have some interest in
On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager grona...@ceptacle.com wrote:
The libcoin/bitcoind client downloads the entire block chain 3.5 times faster
than the bitcoin/bitcoind client. This is less than 90 minutes on a modern
laptop!
Very interesting. Do you know where this speedup came
On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
sync, libbitcoin only made it to height 138k (of course, because the
time is mostly spent late in the chain 138k is not very far along— I'm
guessing it's going to take libbitcoin 3x-4x longer all said)
It ended up
On Thu, Feb 2, 2012 at 12:36 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
sync, libbitcoin only made it to height 138k (of course, because the
time is mostly spent late in the chain 138k is not very far along— I'm
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves supp...@pi.uk.com wrote:
One more thing to add. The implementation in the reference patch fixes
the blockchain forking issue however by still allowing spent coinbases
to be disconnected patched clients are still vulnerable to blockchain
corruption.
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd w...@uchicago.edu wrote:
Dear all,
I am proposing a new opcode for the purposes of anonymous
transactions. This new opcode enables scripts to be given proof that
the receiver can carry out or has carried out a previous transaction.
I'm currently
On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd w...@uchicago.edu wrote:
-My protocol works, your's doesn't. It's not enough to have a mix, the
mix needs to be verifiable to avoid
one of the mixers inserting their own key and removing a key that
should be in there. That doesn't mean you can't
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn m...@plan99.net wrote:
I remember some people, Greg in particular, who were not a fan of
approach (2) at all, though it has the benefit of speeding startup for
new users as there's no indexing overhead.
I'm not a fan of anything which introduces
[I originally sent an earlier version of this message to Mike off
list, but I figure it's worth adding to the public discussion]
On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn m...@plan99.net wrote:
(4) Making the block size limit float is better than picking a new
arbitrary threshold.
On the
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki zgen...@yahoo.com wrote:
Part of the problem is that Satoshi didn't totally anticipate the growth of
the network. The block reward (the subsidy) is too high, which is why
transactions can afford to be so cheap. What would happen if blocks required
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote:
RE: 0x06/0x07 'hybrid' public keys:
Any opinions? Forbidding it certainly makes alternative implementation
slightly easier in the future, but I'm not sure the hassle of a network
rule change is worth it.
I say
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp grarp...@gmail.com wrote:
Well, detachdb doesn't appear in the -\? help
because it's stuffed under pnp, which is not set
in my build. please fix for people, tx :)
It isn't inside the ifdef in bitcoin git master.
(For future reference this sort of
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp grarp...@gmail.com wrote:
It isn't inside the ifdef in bitcoin git master.
Oh, hmm, well then, what is the difference or usage
between these two repositories in regards to the project?
Which one are the formal releases tagged (tbz's cut) in?
Which
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp grarp...@gmail.com wrote:
Presumably the github/0.6.2 branch is safe for production?
0.6.2 is very widely used, more so than the other acceptably updated backports.
What degree of caution about wallet eating should be
made for those using
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner etothe...@gmail.com wrote:
One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
root. Not only would that be disruptive, it would
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn m...@plan99.net wrote:
d'aniel made a good proposal - having good nodes broadcast
announcements when they detect a rule that breaks the rules, along
with a proof that it did so. Checking the proof might be very
Link?
I also proposed this on this
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp grarp...@gmail.com wrote:
You are going to want to include the block of the Phatom project as well:
https://code.google.com/p/phantom/
fd00:2522:3493::/48
Perhaps some argument to add blocks to the IsRoutable check is in
order? Then people who use
Pieter's performance numbers are a bit conservative if anything—
profiles on ultraprune[1] show that the reference client's wasting of
a lot of time in redundant serialization and hashing operations is
the major time sink. Once thats cleared up it should be quite a
bit faster
[1]
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote:
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index refers
to the first such pair that is not already spent. No?
Yes, that is
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón timon.elvi...@gmail.com wrote:
Didn't even know that they were proprietary software bitcoin clients.
Should people trust them? Should the web promote them?
After all, you can't know what they do. What if one of them contains a
back door or something?
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
I've reverted these additions to the page, nothing personal but—
Er, to be clear, I left the android software in because the source is
available (And I'm told its had some review).
I removed the proprietary software
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote:
JS randomisation is bad. People shouldn't need JS to view a webpage.
JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp grarp...@gmail.com wrote:
It already takes a month to build a new blockchain, let alone keep up
with new incoming blocks.
Please fix your software stack. Something is wrong with your system
and I doubt it has much to do with bitcoin. A full sync here
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp grarp...@gmail.com wrote:
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp grarp...@gmail.com wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync
On Mon, Jul 30, 2012 at 4:26 PM, Amir Taaki zgen...@yahoo.com wrote:
Hi,
luke-jr wants me to split this BIP into 3 separate BIPs because he says that
other devs felt it was too unfocused and covered too many topics. However
this discussion took place on IRC, a
It actually took place on
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik jgar...@exmulti.com wrote:
My only response is a weak one: inevitability. It seems likely that
-somebody- will implement their own P2P commands for their own client
subset, even if only a simple use 'getstatus' with strSubVer matching
/FooClient/
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell
matthewmitch...@godofgod.co.uk wrote:
Here is a BIP draft for improving the block relaying and validation so that
it can be done in parallel and so that redundancy can be removed. This
becomes more beneficial the larger the block sizes are.
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
matthewmitch...@godofgod.co.uk wrote:
For some reason sourceforge is not sending me updates anymore but I can see
the replies online…
There could be a slightly more simple protocol which gives all the
transactions hashes and nodes can then
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik jgar...@exmulti.com wrote:
Yeah, my public nodes currently have 2200+ Over time, it gets
cluttered naturally due to the disconnect between what miners mine and
what relayers relay.
Right, this disconnect is why simple scalar measures of mempool
?
This is discussion about transactions which are not in the chain yet.
On 9/23/12, Gregory Maxwell gmaxw...@gmail.com wrote:
There are bursts of weird transactions (e.g. someone was flooding zero
value txn a few weeks ago; before that there were some enormous series
of double-spend induced orphans), and other
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn m...@plan99.net wrote:
If you just want to waste bandwidth of nodes you can connect to nodes
and repeatedly download blocks, or fill the network with fake nodes
that spam random generated transactions to whoever connects. I don't
see how to avoid
On Fri, Oct 26, 2012 at 10:21 AM, Mike Hearn m...@plan99.net wrote:
Anyway, it's trivial to DoS the entire Bitcoin network today. It
hasn't ever happened. Maybe one day it will, but the only rationale
people can come up with for such an attack beyond random griefing is
Which happens and is a
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
I'm concerned about how the particular security model of electrum is
being described; or rather— not being described.
Just to close the loop on this: I finally got in touch with Thomas on
IRC and walked over the security
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
They could be included as well of course, but from a seller
perspective the most important thing is consistency. You have to be
able to predict what CAs the user has,
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote:
X-ISO4217-A3
I see that draft-stanish-x-iso4217-a3 is not standards track, is there
a reason for this?
It also doesn't appear to address ~any of the the targeted items here.
Is there another draft I should be looking for
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote:
Bitcoin aka the blockchain is defined by the majority of the miners. This is
what people have signed up to imo. A scheme that a) is of benefit for us all
and b) is also of economical benefit for the miners, will
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote:
The main source for these 1 Satoshi payouts is Sahtoshi Dice.
Because people are making 1 satoshi bets, or is this part of their
messaging system?
It's part of their messaging system. Every losing play results in a
new 1e-8
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote:
These discussed features are all useful but quite contradicting.
I imagine that a user will be able to switch between different coin
selection policies minimize fees,max privacy,defragmentation,i
don't care and even
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote:
4) A longer term reason - in time, people may choose to not broadcast
transactions at all in some cases. I think how network speed will be
funded post-inflation is still an open question. Assuming the simplest
arrangement
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn m...@plan99.net wrote:
The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
not convinced this is the best use of time, but if somebody steps up
to do it, that could also work.
I strongly believe that if community leads with client
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote:
Alan's
:(
UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged.
No, not really. Somewhat easier due to some structural changes, but it
still needs to invent and get consensus on a
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote:
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
Hardly. I don't have any particular
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote:
Greg's point looks like it's veering towards we don't want to grow
the network unless we're going to get more full nodes out of it.
No…
There is no fundamental completion between taking what actions we can
to maximize the
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote:
Our divergence is on two points (personal opinions):
(1) I don't think there is any real risk to the centralization of the
network by promoting a SPV (purely-consuming) node to brand-new users.
In my opinion (but I'm not
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote:
I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
integers as BIP 32 proposes). For example I name keys like this:
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd w...@uchicago.edu wrote:
being able to spend
a coin sent to an address generated by this scheme implies being able
to spend any coin generated
by this scheme.
If you have the the full extended secret there then you can spend
along the chain— but
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke timo.ha...@web.de wrote:
It's not about technical differences, but about the different use or
purpose, which can result in different security demands. I argue that
DNS has a lower demand in this respect than payment ids have. So DNS
data can be in a
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank raph...@gmail.com wrote:
Has this been considered?
If made sufficiently general, older clients could support any
extension of the rules.
Various hard parameters within the protocol are defined in main.h of
the official client.
In BIP-34, there
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank raph...@gmail.com wrote:
Bitcoin is not a democracy— it quite intentionally uses the consensus
mechanism _only_ the one thing that nodes can not autonomously and
interdependently validate (the ordering of transactions).
So, how is max block size to
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair step...@bitpay.com wrote:
If you've already validated the majority of transactions in a block, isn't
validating the block not all that compute intensive? Thus, it's really not
blocks that should be used to impose any sort of scarcity, but rather
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
I hope that should it become necessary to do so that correct path will
be obvious to everyone, otherwise there is a grave risk of undermining
the justification for the confidence in the immutability of any of the
rules
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote:
One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks they
find...they also have a very strong incentive to hear about the blocks that
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami r...@gnomon.org.uk wrote:
Would be nice to have a secure page at bitcoin.org, though, rathar
than having to go to github - certs from somewhere like Namecheap
should cost you next to nothing. For those of us too lazy (not
paranoid enough) to bother
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote:
The point with UTXO is in the long run to be able to switch from a p2p
network where everyone stores, validates and verifies everything to a DHT
where the load of storing, validating and verifying can be shared.
I
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn m...@plan99.net wrote:
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it isn't presently clear why that particular block
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote:
I don't want to misrepresent what happened, but how much of that was really
a risk? The block was rejected, but the transactions were not.
Some but not much. If someone flooded a bunch of duplicate
concurrently announcing
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote:
Can some enterprising soul determine if there were any double-spend attempts?
I'm assuming no, and if that's the case, we should talk about
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote:
If we're going to consider doing this, at minimum we need to also
I beg people to not derail discussion about fixing things with
discussion of other controversial changes.
Luke-jr, any chance in getting you to revise your
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell
matthewmitch...@thelibertyportal.com wrote:
Why would it be a difficulty in getting people to update away from 0.7 and
earlier? How long would that roughly take? If people are hesitant to update,
imagine if a more serious vulnerability is
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote:
On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
Here's a simple proposal to start discussion from...
It seems to me that the biggest failure was not the development of two
chains, but the assurance to users (by the
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote:
The idea of the client detecting/warning about not-trivial forking
seems worthwhile too, though, assuming it doesn't already (AIUI it
doesn't).
It does warn— if its heard the fork and its on the lower difficulty
side.
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner b...@benlabs.net wrote:
This. Software behavior which is not described by the source code should not
be considered an integral part of the rule set.
Any influence of external libraries on the consensus mechanism is
unacceptable.
No one
On Sat, Mar 23, 2013 at 5:57 PM, Jay F j...@outlook.com wrote:
My first concern was that I and about everyone else only has TCP/UDP
port forwarding,
You tunnel it!
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00
You could do worse to have a data stream that looks like WEBRTC
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote:
I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
universally
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
There was some chat on IRC about a mining pool reaching 46%
http://blockchain.info/pools
The estimates on there may be a bit lossy.
What's the risk of a 51% attack.
The whole fixation on 51 as a magic number is a
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn m...@plan99.net wrote:
but I think p2pool still has a lot of problems dealing with
FPGA/ASIC hardware and it hasn't been growing for a long time.
As an aside and a clarification— P2pool works great with FPGAs, and
one of the largest FPGA farms I've
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter arit...@gmail.com wrote:
Hey guys,
I just bought some BitCoins after being lazy to do it for the last few
years, but also looked at the client code and the messages that are
going on this mailing list.
I saw that there are quite some unit tests,
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle
calebdeli...@lavabit.com wrote:
what anti-virus software might do when certain streams of bytes are sent
across
the tcp socket or persisted to disk. Perhaps worth contacting an AV company
and
asking what is the smallest data they have a
(1) Define a new address type, P2SH^2 like P2SH but is instead
H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is
a hash of a P2SH address.
(2) Make a relay rule so that to relay a P2SH^2 you must include
along the inner P2SH address. All nodes can trivially verify it by
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote:
Of course, either way you have the odd side-effect that it's now
difficult to pay further funds to a random txout seen on the
blockchain... strange, although possibly not a bad thing.
Oh wow, thats actually a quite good
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
Actual network rules will need to come later. However, even just not
accepting them into memory pools will it make very hard (if not impossible)
for the buggy clients that create transactions to get any confirmations.
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net wrote:
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. Everything or two weeks is rather
X most recent is special for two reasons: It meshes well with actual demand,
and
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon
john.dillon...@googlemail.com wrote:
Have we considered just leaving that problem to a different protocol such as
BitTorrent? Offering up a few GB of storage capacity is a nice idea but it
means we would soon have to add structure to the network to
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote:
running hash of all messages sent on a connection so far. Add a new
protocol message that asks the node to sign the current accumulated
hash.
We already depend on OpenSSL, why not just use standard SSL?
SSL doesn't actually
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote:
We don't have non-repudiation now, why make that a requirement for the
first version? Adding non-repudiation is something that has to happen at
the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote:
Maybe I could hack a pool to co-opt it into my netsplit and do the work for
me, or segment enough of the network to have some miners in it, and they do
the work.
Or you can just let it mine honestly and take the Bitcoins.
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com 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
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net 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,
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote:
So the decision has been made to make 0-conf double spends trivial, so no
one will ever trust 0-confs. If a later transaction appears with a
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
arthur.gerv...@inf.ethz.ch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Bitcoin developers,
We would like to report a vulnerability which might lead, under some
assumptions, to a double-spending attack in a fast payment scenario.
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote:
Let me know if you think this is a good idea (or not!)
and if you have any questions.
Being able to promote a fast SPV desktop wallet would be great!
I went through an cycle of testing on multibit after I saw some
complaints
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote:
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
* Very real possibility of an overall net reduction of full nodes on P2P
network
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
MultiBit
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote:
Is the repeatable build infrastructure portable (to any reasonable
mostly-POSIX-compliant system, with gcc or clang)? I have the vague
It's portable to anything that can run the relevant VMs. Uh
provided you don't mind
On Tue, Jul 23, 2013 at 8:54 PM, Wendell w...@grabhive.com wrote:
Forking for curiosity's sake:
Is there a substantial barrier to endian independence in the Bitcoin codebase?
Not really. The software was originally written to write out memory
order to and from the wire, which is part of why the
On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
order to and from the wire, which is part of why the protocol is LE
everywhere,
*before someone corrects me, it's not LE everywhere (I meant
manywhere :P)— there is just enough BE to keep you on your toes. :P
On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. rdohm...@gmail.com wrote:
Secure P2P Email from Friend to Friend without relying on a central server.
Key- / Repleo-Exchange.
Full decentral Email-Network using the Echo Protocol.
Store Email for Offline-Friends in the P2P Network.
Chat and
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote:
I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
told me recently NTRU, which is lattice based, is one of the few (only?)
NIST-recommended QC-resistant algorithms.
Lamport signatures (and merkle
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com wrote:
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node,
[...]
has almost zero drawbacks,
There are whole countries who access the internet from single IP
addresses. There
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some
here might find interesting:
https://bitcointalk.org/index.php?topic=277389.0
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's
On Mon, Aug 19, 2013 at 1:09 PM, Frank F frank...@gmail.com wrote:
If there are technical problems with getwork, maybe they should be addressed
and fixed instead of outright abandoned.
They have been, resulting in a replacement called getblocktemplate
which (presumably) almost everyone talking
On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
I am wondering if we shouldn't have a BIP32 addendum which makes the
following signing related recommendations:
Looks like we're in the midst of another DSA duplicated K disaster.
(Now, blockchain.info mywallet)
I
1 - 100 of 322 matches
Mail list logo
