On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote:
> FWIW, The Open Assets colored coin protocol (CoinPrism) places special
> significance on the zeroth input and the position of the OP_RETURN colored
> coin marker output to distinguish colored coin issuance outputs from
> transfer outpu
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spam
> transactions, the attack succeeds when the attacker is well funded. This
> gives well-funded private and/or public enti
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
> >There will always be a blocksize limit based on technological
> >considerations - the network has a finite bandwidth limit.
>
> A bandwidth limit is not the same as a blocksize limit. Bandwidth
> is unique to every individual. Miners
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote:
> With the 0.01mBTC/KB minimum
> relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
>
> IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and
> $23k/GB (assuming $23 * 1000, as each $2
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote:
> There was this wonderful technology invented a few years ago to deal with
> spam. It's called Hashcash. All these hacky heuristics like block size are
> just dancing around the problem, and the natural solution is already present
>
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
Two other things:
> On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd wrote:
>
> > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > protocols; you haven't taken into account the n
First-seen-safe Replace-by-Fee is now available as a patch against
v0.10.2:
https://github.com/petertodd/bitcoin/tree/first-seen-safe-rbf-v0.10.2
I've also had a pull-req against git HEAD open for a few weeks now:
https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829
I've
On Wed, Jun 10, 2015 at 02:59:48PM -0400, Andy Schroder wrote:
> Hello,
>
> A couple of motivations for a mailing list switch:
>
> 1. Sometimes the mailing list delays delivery for 10 minutes to several
>days.
> 2. There are usually lots of ads at the footer of the messages. Really
>confu
On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote:
>
> Andy Schroder
>
> On 06/10/2015 03:03 PM, Peter Todd wrote:
> >
> >>4. Seems like digital signatures are always broken on messages because
> >>the list server slightly modifies them (?),
On Wed, Jun 10, 2015 at 03:36:42PM -0400, Andy Schroder wrote:
> It's possible that the enigmail extension is not working right, but
> I was under the impression that it is just feeding data to gpg and
> then receiving the response back. It's possible that your e-mail you
> just checked was not sen
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine wrote:
>
> > It could be done by agreeing on a data format and encoding it in an
> > op_return output in the coinbase transaction. If it catches on it could
> > later be enforced with a
On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> The other complication is that this will tend to be a lagging indicator
> based on network congestion from the last time you connected. If we assume
> that transactions are being dropped in an unpredictable way when blocks are
> full,
Summary
---
The BIP66 soft-fork recently passed the 75% support threshold. This
means that 75% of the hashing power has upgraded to support BIP66; 25%
of the hashing power has not. Once 95% of the hashing power has
upgraded, blocks created by the 5% who have not upgraded will be
rejected.
If
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote:
> The configuration used in the code right now simulates two groups of miners
> (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
> internally, but are only connected to each other through a slow 2 Mbit/s
> link.
>
>
Jeff Garzik recently proposed that the upper blocksize limit be removed
entirely, with a "soft" limit being enforced via miner vote, recorded by
hashing power.
This mechanism within the protocol for users to have any influence over
the miner vote. We can add that back by providing a way for transa
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> Nice work, Pieter. You're right that my simulation assumed bandwidth for
> 'block' messages isn't the bottleneck.
>
> But doesn't Matt's fast relay network (and the work I believe we're both
> planning on doing in the near future to
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> Why should miners only be able to vote for "double the limit" or "halve" the
> limit? If you're going to use bits, I think you need to use two bits:
>
> 0 0 = no preference ("wildcard" vote)
> 0 1 = vote for the limit to
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which they
> > claim in th
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > Why should miners only be able to vote for "double the limit" or "h
On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote:
> This is a misguided idea, to say the least. If such a mechanism of of
> user input would be possible, one would use it for transaction
> verification in the first place. In proof-of-stake outcomes are
> determined by vote by stake (that vo
On Sun, Jun 14, 2015 at 11:15:18AM -0400, Jeff Garzik wrote:
> * ACK on moving away from SourceForge mailing lists - though only once a
> community-welcomed replacement is up and running
>
> * ACK on using LF as a mailing infrastructure provider
>
> * Research secure mailing list models, for bitc
On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote:
> I think the whole complexity talk is missing the bigger issue.
>
> Sure, per block validation scales linearly (or quasilinearly…there’s an O(log
> n) term in there somewhere but it’s probably dominated by linear factors at
> curren
On Mon, Jun 15, 2015 at 12:23:44AM +0200, Mike Hearn wrote:
> >
> > One thing that is concerning is that few in industry seem inclined to
> > take any development initiatives or even integrate a library.
>
>
> Um, you mean except all the people who have built more scalable wallets
> over the past
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> On Tue, Jun 16, 2015 at 2:03 AM, Adam Back wrote:
> Dear Adam, All:
>
> At the community's convenience, it would be an honour to arrange an initial
> open summit to meet with representatives of the Chinese miners in Hong Kong
> (UTC+8
On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
> This is very well done.
>
> Have you seen this discussion that I started regarding BIP 63?
>
> https://bitcointalk.org/index.php?topic=1083961.0
>
> I have no response from Peter Todd back on it other than "
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille
> wrote:
>
> > It's simple: either you care about validation, and you must validate
> > everything, or you don't, and you don't validate anything. Sidechains do
> > not offer you a useful
On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:
> Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
> should at least prevent nodes from crashing. When I looked a few days ago I
> only found a few old PRs that seemed to have fallen by the wayside, so this
> n
On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote:
> > Agreed. Pieter Wuille's recent work is a great example of the kind of
> > science-driven investigations that need to be done - and haven't been
> > done very much - to get us some hard data to make decisions on.
> >
>
> Thank you ver
XT nodes.
Secondly, try out my replace-by-fee-tools at:
https://github.com/petertodd/replace-by-fee-tools
You can watch double-spends on the network here:
http://respends.thinlink.com/
References
--
1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
v
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. D
On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote:
> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
No worries, let me know if you have any issues. You have my phone
number.
While my own preference - and a number of other devs - is full-RBF,
either one is a good
On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote:
> I just sent the following email to F2Pool:
>
>
> I was disappointed to see Peter Todd claiming that you have (or will?) run
> his replace-by-fee patch.
>
> I strongly encourage you to wait until most wal
On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:
> >
> > For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transa
On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote:
> > In that case would you enter into such contracts?
> >
>
> We take it as it comes.
>
> Currently, it's perfectly possible to accept zeroconf transactions with
> only a very small chance of double spend. As long as it's only possib
On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote:
> On 2015-06-19 10:39, Peter Todd wrote:
>
> Yesterday F2Pool, currently the largest pool with 21% of the hashing
> power, enabled full replace-by-fee (RBF) support after discussions
> with
>
On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote:
> >
> > Unless you're sybil attacking the network and miners, consuming valuable
> > resources and creating systemic risks of failure like we saw with
> > Chainalysis, I don't see how you're getting "very small" double-spend
> > probab
On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd wrote:
> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> > It is disappointing that F2Pool would enable full RBF when the safe
> > alternative, first-seen-safe RBF, is also available, especially since the
>
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
> >
> > > So connecting to many nodes just because we can and it's not technically
> > > prevented is bad for the network and creating systemic risks of failure,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, an
On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should explicitly
> define one rather than relying on “prima facie” assumptions. Otherwise, I
> would recommend not relying on the existence of a signed transaction as proof
It recently occured to me that we can use the public nature of the block
chain to create trusted identities, for a specific form of trust.
Lets suppose Alice has some bitcoins held at bitcoin address A. She
wants to establish trust in the "identity" associated with the ECC
keypair associated with
On Thu, Apr 26, 2012 at 10:11:51AM -0700, Peter Vessenes wrote:
> These are interesting thoughts, karma for bitcoins essentially.
>
> I would like CoinLab to publish a 'cost of subverting 1-n transactions with
> 90% probability' metric soon, and I think it would help everyone to
> understand what
#220 0x75d021a6 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/libQtGui.so.4
(gdb)
#221 0x75d086fb in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/libQtGui.so.4
(gdb)
#222 0x7582f06c in QCoreApplication::notifyInternal(QObject*,
QEvent*
On Sat, May 26, 2012 at 03:14:40PM +0200, Pieter Wuille wrote:
> On Sat, May 12, 2012 at 3:42 AM, Jeff Garzik wrote:
> > sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have
> > a few IPv6 nodes live on the network already.
> >
> > If you have IPv6, please pull the latest bitcoin
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
> All,
>
> With the flurry of discussion about blockchain compression, I
> thought it was time to put forward my final, most-advanced idea,
> into a single, well-thought-out, *illustrated*, forum post.
> Please check it out: https://bitc
On Mon, Jun 18, 2012 at 12:46:47AM +0200, Alberto Torres wrote:
> Hi,
>
> I did describe a very similar thing back in January (also illustrated,
> and, if I'm not mistaken, more simple and efficient to recalculate),
> and I wanted to do a prototype, but I have been very busy with other
> projects
On Mon, Nov 26, 2012 at 05:37:31PM -0500, Gavin Andresen wrote:
> Why not JSON?
> -
>
> Invoice, Payment and Receipt messages could all be JSON-encoded. And
> the Javascript Object Signing and Encryption (JOSE) working group at
> the IETF has a draft specification for signing JSON data
On Wed, Nov 28, 2012 at 11:43:19AM +0100, Mike Hearn wrote:
> Peter is correct that there are a few degrees of freedom in protobuf
> serialization, though far fewer than with JSON.
FWIW I re-read the specs again and turns out my memory was wrong. (I
last looked at this about four months ago) Dupli
As the title says.
Basically on testnet we should give people the chance to test how their
code handles attempts to spend the genesis block coinbase, as well as
other tx's made to the genesis block address. After all, potentially
Satoshi is still out there, still has that key, and still may cause
I setup a testnet DNS seed using Pieter Wuille's bitcoin-seeder, with
some simple modifications for testnet. It's at
testnet-seed.bitcoin.petertodd.org I also created
static-testnet-seed.bitcoin.petertodd.org which currently has a single A
record pointing to a testnet node I'm running to bootstrap
On Fri, Jan 25, 2013 at 09:23:28PM -0500, Jeff Garzik wrote:
> On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd wrote:
> > Everything is running on a dedicated Amazon EC2 micro instance. Just
> > IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels
> > are br
On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
> First, we have drafted a quite general specification for bitcoin certificates
> (protobuf messages) that allow for a variety of payment protocols (e.g.
> static as well as customer-side-generated payment addresses).
> This part has sur
On Sat, Feb 09, 2013 at 03:33:25PM +0100, Timo Hanke wrote:
> > Why don't you use namecoin or another alt-chain for this?
>
> Because namcoin tries to solve a different problem, DNS, whereas I want
> to establish an identity for a payment protocol. Your incoming payments
> will land on addresses t
In my fidelity bond protocol (1) I'm proposing the use of two possible
new features:
The first is the use of OP_RETURN at the end of a scriptPubKey to
designate that the txout can be immediately pruned as it is obviously
unspendable. My use-case is the publish part of the two-step
publish-sacrific
On Tue, Feb 12, 2013 at 12:42:37PM -0500, Gavin Andresen wrote:
> On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd wrote:
>
> > Again, thoughts?
> >
>
> First: I really like the fidelity bond concept, and want to see it happen.
>
> RE: OP_RETURN : I'v
On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair 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 others
On Wed, Feb 13, 2013 at 05:02:39PM -0800, Gregory Maxwell wrote:
> It's the year 2043— the Y2038 problem is behind us and everyone is
> beginning to forget how terrible it turned out to be— By some amazing
> chance Bitcoin still exists and is widely used. Off-chain system like
> fidelity bonded b
On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote:
> > The idea that miners have a strong incentive to distribute blocks as
> > widely and as quickly as possible is a serious misconception. The
> > optimal situation for a miner is if they can guarantee their blocks
> > would reach just o
In the low-subsidy future fees will be the main source of income for
miners. Thus in some circumstances large miners may even have a reason
to delibrately try to mine a block that would orphan the current best
block. A simple example would be what would happen if a 1000BTC fee tx
was created, but m
Lets suppose we take away everything but the transaction/scripting
system from Bitcoin. What is left is basically a way for to prove that a
set of pubkeys authorized the movement of coins from one place to
another. Of course, such a system is flawed as a currency because of the
double spend problem
On Mon, Feb 25, 2013 at 09:44:58PM -0500, Peter Todd wrote:
> Lets suppose we take away everything but the transaction/scripting
One last thing: credit goes to Gregory Maxwell for his ideas about
adding unspent-chaum-token redemption op-codes to Bitcoin proper that
lead me down the path to
So with UTXO merkle-sum-fee-trees and fraud notices(1) we can
effectively audit the blocks produced by miners and provide a way for
SPV nodes to reject invalid blocks without requiring the whole
blockchain data.
Next step: How do we prevent censorship? Can we at all?
Basically while UTXO-style pr
On Thu, Mar 07, 2013 at 06:00:18AM -0500, Peter Todd wrote:
> It's also notably that auditable off-chain transaction systems are
> vulnerable. All of the trustworthy ones that don't rely on trusted
> hardware require at least some of their on-chain transactions to be
> public
On Thu, Mar 07, 2013 at 06:42:32PM +0100, Mike Hearn wrote:
> To summarize your post - it's another go at arguing for strongly
> limited block sizes, this time on the grounds that large blocks make
> it easier for $AUTHORITY to censor transactions? Is that right?
Yes.
Now, can we solve this probl
As discussed endlessly data in the UTXO set is more costly, especially
in the long run, than transaction data itself. The fee system is per KB
in a block, and thus doesn't properly capture the long-term costs of
UTXO creation.
It's also been suggested multiple times to make transaction outputs wit
On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote:
> My views on censorship resistance in the face of scaling:
>
> 1) I expect if I'm not careful about preserving my privacy with the way I
> use Bitcoin, then I will always run the risk of being censored by miners.
> This means connec
On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote:
> As discussed endlessly data in the UTXO set is more costly, especially
> in the long run, than transaction data itself. The fee system is per KB
> in a block, and thus doesn't properly capture the long-term costs of
&
We can allow for transaction replacement for the purpose of adding fees
to existing transactions safely, and while not increasing the risk of
double-spends by taking advantage of the stubbed out replacement code.
Specifically the replacement code allows for the replacement of a
transaction if a tr
On Tue, Mar 12, 2013 at 10:10:15AM +0100, Mike Hearn wrote:
> There are no bounds on the memory pool size. If too many transactions
> enter the pool then nodes will start to die with OOM failures.
> Therefore it is possible that we have a very limited amount of time
> until nodes start dying en-mas
On Tue, Mar 12, 2013 at 11:10:47AM +0100, Mike Hearn wrote:
> However, most nodes are not running in such a loop today. Probably
> almost no nodes are.
>
> I suppose you could consider mass node death to be more benign than a
> hard fork, but both are pretty damn serious and warrant immediate
> ac
On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
> Following that, increase the soft and hard limit to 1 and eg 10MB, but miners
> should be the last to upgrade.
We just saw a hard-fork happen because we ran into previously unknown
scaling issues with the current codebase. Why fo
On Wed, Mar 13, 2013 at 12:56:29PM +, Luke-Jr wrote:
> Here's a simple proposal to start discussion from...
>
> BEFORE block 262144:
> - Never make a block that, combined with the previous 4 blocks, results in
> over 4500 transaction modifications.
> - Reject any block that includes more than
On Wed, Mar 13, 2013 at 03:26:14PM +, Luke-Jr wrote:
> On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
> > On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd wrote:
> > > If we're going to consider doing this, at minimum we need to also
> >
> > I
On Wed, Mar 13, 2013 at 01:01:43PM -0400, Gavin Andresen wrote:
> > The very statement that we're willing to increase the blocksize as our
> > solution to increased transaction volume rather go down the path of
> > off-chain transactions is incredibly controversial.
>
> I really don't understand t
Hardware mining rigs do not need updating - they all are designed to connect
directly to a pool and it is the pool that makes all block related decisions.
All the miner, or as I prefer to call them hasher, sees is an 80 byte block
header and possibly with stratum and getblocktemplate enough othe
On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote:
> Totally see the logic of this, and it makes sense. But I dont think the
> only risk is in terms of double spend, but rather
>
> 1) vandalize the block chain which may be difficult to unwind?
Vandalize the chain how? By delibratel
On Mon, Apr 08, 2013 at 09:22:10PM -0400, Jeff Garzik wrote:
> http://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/
>
> petertodd: yeah somebody put a file upload tool into the chain
> and then tried to upload the entire amibios source code to it. stupid.
> someone t
On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote:
> hack by changing the protocol. Nodes can serve up blocks encrypted under a
> random key. You only get the key when you finish the download. A blacklist
NAK
Makes bringing up a new node dependent on other nodes having consistent
uptimes
On Tue, Apr 09, 2013 at 04:53:47PM +0200, Mike Hearn wrote:
> there's an obvious backwards compatibility problem there. It should
> probably wait until the payment protocol work is done, so the major user of
> micropayments-as-messages can migrate off them.
As I pointed out in my initial post on
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one uses P2SH addresses yet anyway.
This will restrict data stuffing to
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
> On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
>
> Note how we can already do this: P2SH uses Hash160, which is
> RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
> provides the full 2
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
> On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
>
> Note how we can already do this: P2SH uses Hash160, which is
> RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
> provides the full 2
On Wed, Apr 10, 2013 at 12:15:26AM -0700, Gregory Maxwell wrote:
> On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd 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...
On Wed, Apr 10, 2013 at 05:58:10PM +0200, Jorge Timón wrote:
> On 4/10/13, Peter Todd wrote:
> > Oh, and while we're at it, long-term (hard-fork) it'd be good to change
> > the tx hash algorithm to extend the merkle tree into the txouts/txins
> > itself, which me
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
starts with a header byte ma
On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
> If we're going to extend/expand message signing, can we please add a
> proper ASCII-armored format for it? Really, anything that encodes the
> signed message next to the signature, so that there's no ambiguities
> about what was signed
On Sun, Apr 14, 2013 at 05:26:37AM +, Luke-Jr wrote:
> On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
> > Currently signmessage/verifymessage only supports messages signed by a
> > single key. We should extend that to messages signed by n-of-m keys, or
> > from th
On Mon, Apr 15, 2013 at 04:59:33PM -0700, Pieter Wuille wrote:
> How about: keep a counter in the mempool, remembering the sum of the sizes of
> all replacements a transaction has had. When deciding whether to accept a
> transaction as a replacement, increase this number and then check whether it
Post tge malicious miners and other bits so we can evaluate the system as a
whole.
Mike Hearn wrote:
>This was previously discussed on the forums a bunch of times, but in
>particular here:
>
> https://bitcointalk.org/index.php?topic=91732.0
>
>BTW, I don't think all this has to be solved to r
On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote:
> Gavin do you actually agree with Mike on this stuff like he implies?
> Because if you do, I think people should know. Myself I wouldn't want
> to be contributing to your salary as a foundation member if you don't
> take Bitcoin security
On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote:
> RE: shutting down services dependent on replacement. No, good users of
> replacement would still end up taking priority over the constantly churning
> DoS replacements. The most you can shut down is one contract. Obviously, if
> there's
On Thu, Apr 18, 2013 at 05:04:44AM -0400, Peter Todd wrote:
> An attack still shuts down useful tx replacement though. For instance in
> the adjusting payments example an attacker sets up a legit adjusting
> payment channel, does a bunch of adjustments, and then launches their
>
On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote:
> Let's include bandwidth. Say the contract (multi-sig input + the outputs)
> is about 700 bytes. 43,200 transactions is then about 29 megabytes of data.
> On a fairly normal 10mbit connection that would take about 23 seconds to
> transfer
On Mon, Apr 29, 2013 at 03:48:18AM +, John Dillon wrote:
> We can build this stuff incrementally I'll agree. It won't be the case that
> one
> in a thousand nodes serve up the part of the chain you need overnight. So many
> I am over engineering the solution with BitTorrent.
I think that pret
On Mon, Apr 29, 2013 at 10:30:47PM +0800, Crypto Stick wrote:
> Crypto Stick is an open source USB key for encryption and secure
> authentication.
> We have been accepted as a mentor organization for Google
> Summer of Code (GSOC) 2013. One of our project ideas is to develop a
> physical BitCoin wa
On Fri, May 03, 2013 at 04:06:29PM +0200, Mike Hearn wrote:
> That's true, but we can extend the DNS seeding protocol a little bit - you
> could query .dnsseed.whatever.com and the DNS server
> then only returns nodes it knows matches your requirement.
If you're going to take a step like that, the
On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote:
> > If you're going to take a step like that, the
> > should be rounded off, perhaps to some number of bits, or you'll allow
> > DNS caching to be defeated.
> >
>
> Don't the seeds already set small times? I'm not sure we want these
> re
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote:
More generally, I think this shows clearly how SPV nodes have weaker
security than constantly operating full nodes, which we knew already, so
why not build a better SPV-specific system instead?
I've noticed on my Android phone how it oft
On Mon, May 06, 2013 at 12:20:12PM -0400, Jeff Garzik wrote:
> > Security will be no worse than before - if any one server/seed is honest
> > you're ok - and hopefully better due to the accountability. Obviously
>
> Indeed, the DNS seeds are just servers run by trusted individuals anyway.
Yup, an
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
> Iteration 1) Make it clear in the UI that if the phone is connected to
> WiFi, payments from untrusted people should not be accepted. Currently
> the Android app merely says the money won't be spendable for a few
> minutes. It needs to c
On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 10:19 AM, Peter Todd 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
> >&g
201 - 300 of 578 matches
Mail list logo
