-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015/5/26 21:48, Pieter Wuille wrote:
here is a proposal for how to coordinate future soft-forking
consensus changes:
https://gist.github.com/sipa/bf69659f43e763540550
It supports multiple parallel changes, as well as changes that get
On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.
Now, my question, if replace by
Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
Hello everyone,
here is a proposal for how to coordinate future soft-forking consensus
changes: https://gist.github.com/sipa/bf69659f43e763540550
It supports multiple parallel changes, as well as changes that get
permanently rejected without obstructing the rollout of others.
Feel free to
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
Feel free to comment. As the gist does not support notifying participants
of new comments, I would suggest using the mailing list instead.
I suggest adding a section describing how this interacts with and changes GBT.
Currently, the
It would also help to see the actual code changes required, which I'm sure
will be much shorter than the explanation itself.
On May 27, 2015 5:47 AM, Luke Dashjr l...@dashjr.org wrote:
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
Feel free to comment. As the gist does not support
I think all the suggestions recommending cutting the block time down also
suggest reducing the rewards to compensate.
--
*James G. Phillips IV*
https://plus.google.com/u/0/113107039501292625391/posts
http://www.linkedin.com/in/ergophobe
*Don't bunt. Aim out of the ball park. Aim for the company
Very interesting Matt.
For what it's worth, in future bitcoinj is very likely to bootstrap from
Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily
working towards Tor by default. So this approach will probably stop working
at some point. As breaking PorcFest would kind of
On 05/25/2015 11:05 PM, Peter Todd wrote:
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
I see this behavior all the time. I am using the latest release, as far as
I know. Version 4.30.
The same behavior occurs in the Testnet3 variant of the app. Go in there
with an
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
What prevents RBF from being used for fraudulent payment reversals?
Pay 1BTC to Alice for hard goods, then after you receive the goods
broadcast a double spend of that transaction to pay Alice nothing? Your
only cost is the higher network fee of the 2nd tx.
Thanks,
-Danny
On Mon, May 25, 2015
The general idea for replace by fee is that it would be restricted so
as to make it safe, eg all the original addresses should receive no
less bitcoin (more addresses can be added).
The scorched earth game theory stuff (allowing removing recipients) is
kind of orthogonal.
Adam
On 26 May 2015 at
What prevents you from writing a bad check using today's systems?
On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.tho...@gmail.com
wrote:
What prevents RBF from being used for fraudulent payment reversals?
Pay 1BTC to Alice for hard goods, then after you receive the goods
broadcast a
See the first-seen-safe replace-by-fee thread
Aaron Voisine
co-founder and CEO
breadwallet.com
On Tue, May 26, 2015 at 11:22 AM, Danny Thorpe danny.tho...@gmail.com
wrote:
What prevents RBF from being used for fraudulent payment reversals?
Pay 1BTC to Alice for hard goods, then after you
Hello Mike,
Are you aware of my proposal for network assurance contracts?
Yes I am aware of that; sorry for not mentioning it. I think it is an
interesting proposal, but I would not rely on it today, because it
includes a large share of unproven social experiment.
(Bitcoin too is a social
Thanks.
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
I am not the one presenting this as some kind of novel attack on
transactions in general.
On Tue, May 26, 2015 at 1:43 PM, Raystonn rayst...@hotmail.com wrote:
Trust, regulation, law, and the threat of force. Are you serious?
On 26 May 2015 11:38 am, Allen Piscitello
On Tuesday, 26 May 2015, at 11:22 am, Danny Thorpe wrote:
What prevents RBF from being used for fraudulent payment reversals?
Pay 1BTC to Alice for hard goods, then after you receive the goods
broadcast a double spend of that transaction to pay Alice nothing? Your
only cost is the higher
On Tue, May 26, 2015 at 5:54 PM, Tom Harding t...@thinlink.com 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 understand a specific case
where this makes a difference.
It appears to be a
Trust, regulation, law, and the threat of force. Are you serious?
On 26 May 2015 11:38 am, Allen Piscitello allen.piscite...@gmail.com wrote:What prevents you from writing a bad check using todays systems?On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.thorpe@gmail.com wrote:What prevents RBF
You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
and you have big banks as clients. Shit like replace-by-fee and leading
the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
Peter Todd - 8930511 Canada Ltd.
1214-1423 Mississauga Valley Blvd.
Mississauga
Please let's at least have some civility and decorum on this list.
On Tue, May 26, 2015 at 1:30 PM, joli...@airmail.cc wrote:
You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
and you have big banks as clients. Shit like replace-by-fee and leading
the anti-scaling mob is
Apologies if this has already been stated and I missed it, but:
Can transactions in a buried block be overridden/replaced by RBF?
Or is RBF strictly limited to transactions that have not yet been
incorporated into a block?
Thanks,
-Danny
On Mon, May 25, 2015 at 10:13 PM, Peter Todd
It's just a mempool policy rule.
Allowing the contents of blocks to change (other than by mining a competing
chain) would be pretty much the largest possible change to Bitcoin's
design
--
What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.
Now, my question, if replace by fee doesn't allow me to change the
inputs or the outputs, I
Hi all,
some time ago, we became interested in Bitcoin, but gathering relevant
work and getting an overview was kind of painful. We took it as a sign
that a survey paper on Bitcoin is desperately needed.
Since then we observed the activities of the Bitcoin community. Recently
we finished a
Hi Florian!
On 2015-05-26 15:54, Florian Tschorsch wrote:
some time ago, we became interested in Bitcoin, but gathering relevant
work and getting an overview was kind of painful. We took it as a sign
that a survey paper on Bitcoin is desperately needed.
Since then we observed the activities
Well so for example it could have an additional input (to increase the
BTC paid into the transaction) and pay more to an existing change
address and higher fee, or add an additional change address, and leave
a larger fee, or if you had a right-sized coin add an additional input
that all goes to
That attitude and doxxing is not appropriate for this list.
On Tue, May 26, 2015 at 4:30 PM, joli...@airmail.cc wrote:
You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
and you have big banks as clients. Shit like replace-by-fee and leading
the anti-scaling mob is for
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 of a weeblix for how informative it is, since you've
Thanks for the clarification.
So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement
I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra
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 of a
33 matches
Mail list logo
