You're only strengthening Gigas' point about the mailing list by posting
derisive emails. Take your nonconstructive comments elsewhere.
- Jameson
On Fri, Jun 19, 2015 at 4:01 PM, Brian Hoffman brianchoff...@gmail.com
wrote:
damn he was just on the verge of solving the underlaying problem with
It seems to me that FSS RBF must enforce identical OP_RETURN data on the output
scripts as the first seen transaction, as well, to safely continue support for
various other applications built atop the blockchain.
Is there a canonical implementation of FSS RBF around somewhere I can review?
On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all.
Retail POS merchants probably should
damn he was just on the verge of solving the underlaying problem with Bitcoin
and you interrupted his focus.
On Jun 19, 2015, at 3:55 PM, John Bodeen john-bod...@uiowa.edu wrote:
from their website, humorous bits highlighted
October 14, 2014
In latest Hiatus new, the company has taken
I'm not sure I understand your question about the need to store paths in
the wallet database -- there's no way to infer the path of an address
inside an HD wallet from the address alone (short of an exhaustive
search), and HD wallets need to store either the paths, addresses, or
both that have
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
They don't need to be made cryptographically safe, they just have to be
safer than,
On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.
They never will be. You can get
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at
wrote:
I have
It all comes down to managing risk. If you’ve got a decent risk model with
capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine.
But most payment processors and merchants right now probably don’t have
particularly good risk models and are making many dangerous
I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar
m/##'/0'/99'/0'
where 99 is the identifier for, say, counterparty
What is stopping you from using m/44'/9'/a'/c/i as descibed here:
http://doc.satoshilabs.com/slips/slip-0044.html
to avoid having an internal mapping from 9'- 0' to find out what
blockchain to query, this sounds like it should
Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which
is what your proposed path structure would be, and it results in the
address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w.
When the wallet notices a transaction in the blockchain that has
1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an
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
I don’t think the issue is between larger blocks on the one hand and things
like lightning on the other - these two ideas are quite orthogonal.
Larger blocks aren’t really about addressing basic scalability concerns - for
that we’ll clearly need architectural and algorithmic improvements…and
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 wallet software supports
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
the full RBF is. We are going to switch to FSS RBF in a few hours.
Sorry.
On Fri, Jun 19, 2015
On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn m...@plan99.net wrote:
We already removed the footer because it was incompatible with DKIM
signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible
with DKIM header signing only if the poster manually prepends it in their
subject
Yeah, but increasing block-size is not a longterm solution.
Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.
Satoshi thought it was a perfectly fine long term solution because he
thought hardware
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 transactions could be for the
80% to not build on blocks containing doublespends by
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. Did
Hi Adam,
I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this layer 2 you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will
Extremely disappointed to hear this. This change turns double spending from
a calculable (and affordable) risk for merchant payment processors into
certain profit for scammers, and provides no useful benefit for consumers.
I sincerely hope that F2Pool reconsider, given that RBF will decrease the
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse
stephencalebmo...@gmail.com wrote:
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since
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. Did they consider using FSS RBF instead?
Best,
Stephen
On Fri, Jun
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 transactions
Chun Wang 1240902 at gmail.com writes:
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
FSS RBF is better than no RBF but we think it is better to use full RBF.
We think Full RBF is better for a number of reasons:
-user experience
-efficiency
-cost
-code complexity
We
IPv4 came before IPv6…you pick up on things quickly :)
On Jun 19, 2015, at 5:48 AM, Marcel Jamin mar...@jamin.net wrote:
At the risk of stating cliches, the Mac came before the Windows PC…Yahoo!
came before Google…MySpace came before Facebook…
And TCP/IP came before... oh wait...
A lot of standpoints for keeping the current block size are focused on
creating a healthy fee market. I have some open questions for this list
in regards to the user incentives of using bitcoin, when such a strong
fee market is in place.
In my scenario the average fee for a normal transactions
When is the right time to allow space pressure to rise that ratio?
When the subsidy is at 1.5625, for example, it may be too late to
I don¹t believe we have to decide, the miners will do that and are doing
that already.
start a non-catastrophic transition from subsidies to fees.
I don't claim
On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org
mailto:a...@cypherspace.org wrote:
That wont be good for the companies either, but they may not see that
until they've killed it, many companies operate on a1 or 2 year
time-horizon. They may say screw layer2, I have a runway
Yeah, but increasing block-size is not a longterm solution. Necessary
higher fees are a logical consequence of lower subsidies. Bitcoin was
basically free to use at the beginning because miners got paid with
new coins at the expense of those who already hold coins. Eventually
there needs to be a
Benjamin,
Timeframe for network congestion and users experiencing service
degradation = between now and middle of next year.
Timeframe for transaction fees topping block reward fees = many years in
the future, based on current ratio of block reward to fees.
What is the more pressing requirement
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net wrote:
Or alternatively, fix the reasons why users would have negative
experiences with full blocks
It's impossible, Mark. *By definition* if Bitcoin does not have
sufficient capacity for everyone's transactions, some users who
Both you and jgarzik experienced mail getting tossed into gmail's spam
folder thanks to DKIM... I am concerned that DKIM is too fragile and not
very compatible with mailing lists.
We already removed the footer because it was incompatible with DKIM
signing. Keeping the [Bitcoin-dev] prepend tag
Or alternatively, fix the reasons why users would have negative
experiences with full blocks
It's impossible, Mark. *By definition* if Bitcoin does not have sufficient
capacity for everyone's transactions, some users who were using it will be
kicked out to make way for the others. Whether
We already removed the footer because it was incompatible with DKIM
signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible
with DKIM header signing only if the poster manually prepends it in their
subject header.
I still see footers being added to this list by
The new list currently has footers removed during testing. I am not
pleased with the need to remove the subject tag and footer to be more
compatible with DKIM users.
Lists can do what are effectively MITM attacks on people's messages in any
way they like, if they resign for the messages
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com wrote:
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 15:11, Peter Todd wrote:
If you ask me to pay you 1BTC at address A and I create tx1 that pays
1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
Yes, FSS RBF is far better.
On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang 1240...@gmail.com wrote:
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know
OK, a few things here:
The Bitcoin network was designed (or should be designed) with the requirement
that it can withstand deliberate double-spend attacks that can come from
anywhere at any time…and relaxing this assumption without adequately assessing
the risk (i.e. I’ve never been hacked
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
me. This means that
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
probabilities.
So connecting to many nodes just because we can and it's not
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org wrote:
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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
me. This means that transactions that F2Pool has
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 possible to
Great. Thank you for this!
Adrian
On Fri, Jun 19, 2015 at 7:40 AM, Chun Wang 1240...@gmail.com wrote:
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com
wrote:
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant
This is very disappointing. scorched earth replace-by-fee implemented
first at a pool, without updating wallets and merchants, is very
anti-social and increases the ability to perform Finney attacks and
double-spends.
The community is progressing more towards a safer replace-by-fee model, as
We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
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
fees they would gain by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 16:36, Matt Whitlock wrote:
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
I'd also like to note that prima facie doesn't mean always, it
means
that the default assumption, unless proven otherwise.
Why
prima facie generally means that in a court case the burden of proof
shifts from one party to another. For instance, if you have a federal
trademark registration that is prima fascia evidence of those rights
even though they could still be challenged. To say a prosecutor would
have prima
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
I'd also like to note that prima facie doesn't mean always, it means
that the default assumption, unless proven otherwise.
Why would you automatically assume fraud by default? Shouldn't the null
hypothesis be the default?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 16:42, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 15:37, Eric Lombrozo wrote:
OK, a few things here:
The Bitcoin network was designed (or should be designed) with the
requirement that it can withstand deliberate double-spend attacks that
can come from anywhere at any time…and
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, and
Gregory
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
- Did you accept payment from companies to lobby for 20MB blocks? Do
you consider that something appropriate to publicly disclose if so? Do
you consider that user rights should come above or below company
interests in Bitcoin? FWIW on pondering that last question should user
rights come above
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, and
Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
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 of
intent to pay…
On Jun 19, 2015, at 9:36 AM, Matt Whitlock
Even if you could prove intent to pay, this would be almost useless. I can
sincerely intend to do a lot of things, but this doesn't mean I'll ever
actually do them.
I am in favor of more zero-confirmation transactions being reversed /
double-spent. Bitcoin users largely still believe that
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo elombr...@gmail.com 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
This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.
Thanks
--
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 17:50, Jeff Garzik wrote:
No. You cannot know which is the 'right' or wrong transaction. One tx
has
obvious nSequence adjustments, the other - the refund transaction - may
not.
I'm still not seeing a case where a node could
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net wrote:
If we have ECDSA proof that an entity intentionally made and publicly
announced incompatible promises regarding the disposition of particular
Bitcoins under their control, then why shouldn't that be assumed to be a
fraud attempt
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net wrote:
On 2015-06-19 17:40, Jeff Garzik wrote:
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.
Is there not a dedicated field in a transaction (nSequence) for express
from their website, humorous bits highlighted
*October 14, 2014 *In latest Hiatus new, the company has taken on yet
another crazy project but this one is going to benefit the world in which
it entered not long ago. The company had done a lot of research on crypto
currencies, built one for
You are free to remove yourself; the URL is at the bottom of every email:
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc.
corpor...@gigasgaming.com wrote:
This is no longer a mailing list, this is a chatroom.
Please remove
70 matches
Mail list logo
