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.
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
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's goal is to confirm only transactions all
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 publication
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
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 t...@thinlink.com wrote
is .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's say he saw it 21
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
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 enough
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 at
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
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 t...@thinlink.com
mailto:t...@thinlink.com wrote:
...
If nLockTime is used for expiration, transaction creator can't
lie
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,
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,
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 AS
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 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
much appreciated.
It is not yet implemented anywhere.
Cheers,
Tom Harding
CA, USA
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https
: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://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
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 others
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 Harding wrote:
So, I think
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?
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
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
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
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
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
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 it
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 scenarios in
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/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 size.
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, increasing
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
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/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 extra
On Jun 6, 2015 8:05 AM, Kalle Rosenbaum ka...@rosenbaum.se 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
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 network
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 an
mailto:ka...@rosenbaum.se:
2015-06-06 18:10 GMT+02:00 Tom Harding t...@thinlink.com
mailto:t...@thinlink.com:
On Jun 6, 2015 8:05 AM, Kalle Rosenbaum
ka...@rosenbaum.se mailto:ka...@rosenbaum.se wrote:
I'm open to changes here.
I suggest
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 necessary
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/26/2015 4:11 PM, Gregory Maxwell wrote:
On Tue, May 26, 2015 at 11:00 PM, Tom Harding t...@thinlink.com 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 say that its
part
43 matches
Mail list logo
