On 6/20/2015 5:54 PM, Eric Lombrozo wrote:
> Perhaps it isn’t prudent to push out changes to the relay policy that make
> these exploits even easier right now - but we NEED to be applying some kind
> of pressure on the merchant end to upgrade their stuff to be more resilient
> so that we have mo
On 6/19/2015 6:43 AM, Mike Hearn wrote:
> No surprise, the position of Blockstream employees is that hard forks
> must never happen and that everyone's ordinary transactions should go
> via some new network that doesn't yet exist.
If my company were working on spiffy new ideas that required a hard
On 06/12/2015 06:51 PM, Pieter Wuille wrote:
>> However, it does very clearly show the effects of
>> larger blocks on centralization pressure of the system.
On 6/14/2015 10:45 AM, Jonas Nick wrote:
> This means that your scenario is not the result of a cartel but the result of
> a long-term netwo
"Increase DEFAULT_BLOCK_MAX_SIZE to 1MB"
https://github.com/bitcoin/bitcoin/pull/6231
On 6/17/2015 8:28 AM, Raystonn . wrote:
> Wow. That email was delayed by the list for quite some time. It was
> sent on 6/1.
>
>> I also need to argue for increasing the default block limit to the
>> full 1M
On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>> Kalle goes to some trouble to describe how merchants need to ensure that
>> they only accept a PoP provided as a response to their challenge.
>>
> Do you mean that it will be hard to e
pt the PoP-request and change any
> parameter in it.
> >> These can be mitigated by using secure connections. For example:
> >> ** Pop destination - Stealing your PoP.
> >> ** label - Trick you to sign an unintended pop or set a label
> that your
>
On 6/11/2015 6:10 AM, Peter Todd wrote:
> 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
In September, 2014, a collective experiment began in the bitcoin
ecosystem. Available block space (1MB) began to sometimes fall short of
the space required to mine all of the transactions that would otherwise
have been included.
This chart, posted earlier, shows the onset of the
some-blocks-at-ma
On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" wrote:
> I'm open to changes here.
I suggest:
- Don't include any real outputs. They are redundant because the txid is
already referenced.
- Start the proof script, which should be invalid, with a magic constant
and include space for future expansion
On 6/1/2015 10:21 AM, Adam Back wrote:
> if it stays as is for a year, in a wait and see, reduce spam, see
> fee-pressure take effect as it has before, work on improving improve
> decentralisation metrics, relay latency, and do a blocksize increment
> to kick the can if-and-when it becomes necessar
On 5/26/2015 4:11 PM, Gregory Maxwell wrote:
> On Tue, May 26, 2015 at 11:00 PM, Tom Harding wrote:
>> The bitcoin transaction is part of a real-world "deal" with unknown
>> connections to the other parts
> I'm having a hard time parsing this. You might as well
On 5/26/2015 12:10 PM, Gregory Maxwell wrote:
> On Tue, May 26, 2015 at 5:54 PM, Tom Harding wrote:
>> It's not difficult to
>> imagine real-world consequences to not having contributed to the
>> transaction.
> I'm having a hard time. Can you help me under
I think this is a significant step forward.
I suggest you also need to ensure that no inputs can be removed or
changed (other than scriptsigs) -- only added. Otherwise, the semantics
change too much for the original signers. Imagine a tx with two inputs
from different parties. Should it be
On 5/16/2015 1:35 PM, Owen Gunden wrote:
> There are alternatives that still use bitcoin as the unit of value,
> such as sidechains, offchain, etc. To say that these are "not bitcoin"
> is misleading.
Is it? Nobody thinks "euro accepted" implies Visa is ok, even though
Visa is just a bunch of ex
A recent post, which I cannot find after much effort, made an excellent
point.
If capacity grows, fewer individuals would be able to run full nodes.
Those individuals, like many already, would have to give up running a
full-node wallet :(
That sounds bad, until you consider that the alternative
On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>
> G proposed 20MB blocks, AFAIK - 140 tps
> A proposed 100MB blocks - 700 tps
> For ref,
> Paypal is around 115 tps
> VISA is around 2000 tps (perhaps 4000 tps peak)
>
> I ask again: where do we want to go? This is the existential
> question behind block
On 5/7/2015 6:40 AM, Jorge Timón wrote:
>> Known: There's a major problem looming for miners at the next block reward
>> halving. Many are already in a bad place and without meaningful fees then
>> sans a 2x increase in the USD:BTC ratio then many will simply have to leave
>> the network, increasin
On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> In the short term, blocks are bursty, with some on 1 minute intervals,
> some with 60 minute intervals. This does not change with larger blocks.
>
I'm pretty sure Alan meant that blocks are already filling up after long
inter-block intervals.
>
> 2)
On 5/6/2015 3:12 PM, Matt Corallo wrote:
Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full.
I think it's way too early to even consider a future era when the fiat
value of the block reward is no longe
On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote:
>
> I've built a proof-of-concept for Proof of Payment. It's available at
> http://www.rosenbaum.se:8080. The site contains links to the source
> code for both the server and a Mycelium fork as well as pre-built apk:s.
>
>
> >> There are several scen
On 3/26/2015 2:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding wrote:
>> I should have been clearer that the motivation for address expiration is to
>> reduce the rate of increase of the massive pile of bitcoin addresses out
>> there which have to
On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> Which is why a simpler, safer, client enforced behavior is probably
> preferable. Someone who wants to go hack their client to make a
> payment that isn't according to the payee will have to live with the
> results, esp. as we can't prevent that in a s
On 3/25/2015 12:22 PM, Gregory Maxwell wrote:
>
> Verification with duplicate elimination requires O(N) storage (with N
> being the length of the history), since you need to track all the
> duplicates to reject.
>
I addressed that by limiting the duplicate check to an X-block segment.
X is hard-
On 3/25/2015 9:34 AM, Gregory Maxwell wrote:
>
>> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
> Assuming the sender is not an uncooperative idiot, you can simply
> include expiration information and the sender can refuse to send after
> that time.
Is this assuming payment protocol? A majo
The idea of limited-lifetime addresses was discussed on 2014-07-15 in
http://thread.gmane.org/gmane.comp.bitcoin.devel/5837
It appears that a limited-lifetime address, such as the fanciful
address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
where 349366 is the last valid block for a transaction
On 2/22/2015 9:12 AM, Peter Todd wrote:
> Did you notice the even more obvious way to defeat ANYONECANPAY
> scorched earth with that patch?
Let's see. I could pay 10 people 1 BTC each with one tx, then
double-spend it with fees of 2BTC. Now at least three of the 10 have to
work together if t
On 2/11/2015 10:47 PM, Peter Todd wrote:
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
>
This patch immediately simplifies successful double-spends of
unconfirmed transactions. But the idea that
On 2/12/2015 6:25 AM, Tamas Blummer wrote:
>
> Miner will see a mixed picture and will struggle to act “honestly” on
> a statistical measure.
The statistics come from the aggregate actions of all nodes, especially
those miners who watch p2p transactions and assemble blocks.
Any one node makes d
On 2/11/2015 10:47 PM, Peter Todd wrote:
> ... replace-by-fee ...
Replace-by-fee creates the power to repudiate an entire tree of
payments, and hands this power individually to the owner of each input
to the top transaction. Presumably this is why the original replacement
code at least require
Many thanks for the feedback Peter. Please if you would, see below
On 2/8/2015 10:32 PM, Peter Todd wrote:
> Seeing a transaction is not a guarantee that any other node has seen it; not
> seeing a transaction is not a guarantee other nodes have not seen a spend.
In no way does proposal rely on
This update strengthens the incentive not to confirm double-spends after
time T (30 seconds). To grow and stabilize adoption, it is necessary to
influence the miner of the block after a deprecated block, who in turn
is concerned with the block after that. Accordingly, the disincentive is
chan
On 1/31/2015 5:11 AM, Wladimir wrote:
> The block chain is a single channel broadcasted over the entire world,
> and I don't believe it will ever be possible nor desirable to
> broadcast all the world's transactions over one channel.
>
> The everyone-validates-everything approach doesn't scale. I
On 1/17/2015 12:45 PM, Rune Kjær Svendsen wrote:
> PDF: http://impulse.is/impulse.pdf
>
> I'd love to hear this list's thoughts.
>
Will success be defined by "BitPay Payment Channels Accepted Here" signs
appearing in shop windows?
ess than 30
seconds after first seen, he should expect 5 of 1 nodes to delay his
block.
Hal Finney remarked that this idea would need "careful analysis." More
help is very welcome.
https://bitcointalk.org/index.php?topic=3441.msg48789#msg48789
Cheers!
On 10/28/2014 10:38 AM, Tom H
On 10/27/2014 7:36 PM, Gregory Maxwell wrote:
> Consider a malicious miner can concurrently flood all other miners
> with orthogonal double spends (which he doesn't mine himself). These
> other miners will all be spending some amount of their time mining on
> these transactions before realizing oth
nds completely.
On 10/27/2014 1:17 PM, Matt Corallo wrote:
> miners are incentivized to go connect to everyone on the network and
> look for double-spends
>
> On 10/27/14 19:58, Tom Harding wrote:
>> https://gi
much appreciated.
It is not yet implemented anywhere.
Cheers,
Tom Harding
CA, USA
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https
On 10/7/2014 8:50 AM, Gavin Andresen wrote:
>
> I don't have any opinion on the hard- versus soft- fork debate. I
> think either can work.
>
Opinion: if a soft work works, it should be preferred, if for no other
reason than once a hard-fork is planned, the discussion begins about
what else to t
I'm stunned by what bitcoinj can do these days. Just reading the
release notes gives one app ideas. Mike, Awesome.
On 10/3/2014 5:49 AM, Mike Hearn wrote:
I'm pleased to announce version 0.12 of bitcoinj, one of the worlds
most popular Bitcoin libraries.
-
On 9/25/2014 7:37 PM, Aaron Voisine wrote:
> Of course you wouldn't want nodes to propagate alerts without
> independently verifying them
How would a node independently verify a double-spend alert, other than
by having access to an actual signed double-spend?
#4570 relays the first double-spend A
Having explored more drastic approaches, it looks like Kaz' basic idea
stands well. His #1...
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
is already implemented in bitcoin-qt #2340
Today we have first-eligible-height (nLockTime), and mempool expiration
measured from this height would work for the goals being discussed, no
fork or protocol rev.
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition, lo
nd to rewrite their nLockTime,
if it fails to be confirmed before some arbitrary deadline being set.
On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding mailto:t...@thinlink.com>> wrote:
...
If nLockTime is used for expiration, transaction creator can't
lie
On 8/5/2014 12:10 PM, Kaz Wesley wrote:
> Any approach based on beginning a transaction expiry countdown when a
> transaction is received (as in mempool janitor) seems unviable to me:
> once a node has forgotten a transaction, it must be susceptible to
> reaccepting it;
It's hard to argue with
On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> 1. start setting nLockTime to the current height by default in newly
> created transactions (or slightly below the current height, for
> reorg-friendliness)
Reorg-frendliness is the opposite of the rationale behind #2340, which
proposes setting nLockTime
On 6/16/2014 8:48 AM, Mike Hearn wrote:
> In practice of course this is something payment processors like Bitpay
> and Coinbase will think about. Individual cafes etc who are just using
> mobile wallets won't be able to deal with this complexity: if we can't
> make native Bitcoin work well enoug
On 6/16/2014 8:09 AM, Daniel Rice wrote:
> What if we solved doublespends like this: If a node receives 2
> transactions that use the same input, they can put both of them into
> the new block as a proof of double spend, but the bitcoins are not
> sent to the outputs of either transactions. They
.0025 BTC,
still quite high for one transaction. I guess miner could try to make a
business out of mining double-spends, to defray that cost.
On 5/11/2014 9:41 PM, Tom Harding wrote:
> Back up to the miner who decided to include a "seasoned" double-spend
> in his block. Let&#x
Christophe Biocca wrote:
> The problem is that since the rule
> isn't enforceable, no miner will wait before mining on the longest
> chain (which is the rational move), and you're back to where we are
> now.
Back up to the miner who decided to include a "seasoned" double-spend in
his block. Let
Christophe Biocca wrote:
> it becomes trivial with a few tries to split the network into two
> halves: (tx1 before tx2, tx2 before tx1).
"before" implies T=0. That is a much too optimistic choice for T; 50%
of nodes would misidentify the respend.
> Tom Harding wrote:
This idea was suggested by "Joe" on 2011-02-14
https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It
deserves another look.
Nodes today make a judgment regarding which of several conflicting
spends to accept, and which is a double-spend. But there is no
incorporation of these c
On 4/23/2014 2:23 PM, Tier Nolan wrote:
> An interesting experiment would be a transaction "proof of
> publication" chain.
What if a transaction could simply point back to an earlier transaction,
forming a chain? Not a separately mined blockchain, just a way to
establish an official publicati
On 4/22/2014 9:03 PM, Matt Whitlock wrote:
> On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
>> A network where transaction submitters consider their (final)
>> transactions to be unchangeable the moment they are transmitted, and
>> where the network'
Since no complete solution to preventing 0-confirmation respends in the
bitcoin network has been proposed, or is likely to exist, when
evaluating partial solutions let's ask "what kind of network does this
move toward?"
Does the solution move toward a network with simple rules, where the
cert
Jonathan -
These are a few things I've been wishing for recent data on:
- 95th percentile transaction propagation time vs. fees/kb, vs. total fees
- Count of blocks bypassing well-propagated transactions vs. fees/kb,
vs. total fees
- Signed-double-spend confirmation probability vs. broadca
On 4/7/2014 7:05 AM, Mike Hearn wrote:
> Some days I wonder if Bitcoin will be killed off by people who just
> refuse to use it properly before it ever gets a chance to shine. The
> general public doesn't distinguish between "Bitcoin users" who deposit
> with a third party and the real Bitcoin u
56 matches
Mail list logo
