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
What prevents RBF from being used for fraudulent payment reversals?
Pay 1BTC to Alice for hard goods, then after you receive the goods
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 allen.piscite
You cannot close Pandora's box. Whether or not this type of patch should
exist is irrelevant. It does, and there are incentives to use it by
miners. These are the bounds we have to deal with and the world we must
On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
Nothing will stop that. Bitcoin needs to deal with those issues, not stick
our heads in the sand and pretend they don't exist out of benevolence.
This isn't a pet solution, but the rules of the protocol and what is
realistically possible given the nature of distributed consensus. Relying
You are assuming that the only way to use Bitcoin is on-chain transactions
and that is the only way for it to scale. This is a mistake.
On Fri, Jan 30, 2015 at 6:48 PM, Angel Leon gubat...@gmail.com wrote:
On the Chinese Single's Day (sort of like the american Black Friday)
according to MIT's
Don't most of these coins have a magic number already assigned that is
unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
Litecoin, etc...). This seems like a good candidate for identifying coins,
and also supports Testnet cases well. Maybe there are some alts without
types of losses will occur when someone tests out
something with a limited use case, sees that it appears to work, makes
dangerous assumptions, then gets burned when it's too late.
On Thu, Mar 27, 2014 at 11:06 AM, Pavol Rusnak st...@gk2.sk wrote:
On 03/27/2014 04:57 PM, Allen Piscitello
The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
For every branch (say multiple accounts), how would a new wallet be able to
know how many sequence items to scan? It seems like not only do you need
to have standard rules for the hierarchy, but how the usage can be
detected. The other scanning seems pretty straightforward. For accounts,
Fairly useless experiment, since the vast majority of users will almost
always stay at the default. The winner will always be whatever was
selected as the default initially. This might work if the default was
randomly chosen, and you see what actually annoyed users enough to switch
off of it
Mike is making an assumption that is not necessary, which is the price of
the most commonly used unit should be between is $.50 and $1000. The issue
to revisit or not shouldn't require $1,000,000 Bitcoin price. Typing a ton
of decimals is incredibly annoying. Doing the mental math in my head is
It certainly is not subjective, in that people are far more used to dealing
with whole numbers than decimals. Try reading the first one, then reading
the second one. Tell those numbers to someone else, have them write it
down, and see how many people screw up the first vs. the second. This has
This is somewhat problematic in my use case since some parts need to be in
the chain earlier than others and have the same ID as expected.
I haven't gone back to see if there are any ways around it, but the main
problem here is I need the
While that solution does work for many use cases, it does make it much
harder to do anything needing chained transactions. Granted, this is the
short term solution for current implementations, but having a transaction
identifier that does not change does open up other use cases.
No, you don't get it, and it's been explained clearly to you twice. Take
it to bitcointalk, this does not belong on this list. Your cure is worse
than the disease.
On Wed, Dec 25, 2013 at 12:53 AM, Ryan Carboni ryan.jc...@gmail.com wrote:
You just completely ignored my point. I'm not sure
Why do you continue to try to correct people who clearly have put more
thought into this than you? Everyone understood you just fine, you just
seem to have trouble comprehending why your ideas are terrible.
On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni ryan.jc...@gmail.com wrote:
I've got a better idea. Ben Bernake needs a new job. Let's just let him
set the block reward.
On Mon, Dec 9, 2013 at 5:23 PM, Jameson Lopp jameson.l...@gmail.com wrote:
To piggyback on Jeff,
Any proposal that is going to add reliance upon data from third parties
outside of the Bitcoin
taken into consideration when it comes to user perception (which is one of
the reasons we would make such a change in the first place).
Holy crap these fees are huge! I thought Bitcoin didn't have fees!
On 11/14/2013 04:55 PM, Allen Piscitello wrote:
I also would prefer to go straight
This was one of my concerns when implementing a scheme where you sign a
refund transaction before the original transaction is broadcast. I
originally tried to pass a hash and have the server sign it. However, I
had no way to know that what I was signing wasn't a transaction that was
, 2013 at 8:27 PM, Luke-Jr l...@dashjr.org wrote:
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed
The problem with this is that you might have word A which is similar to B,
but B is also similar to C. So we scrub B from the list, someone enters B,
and we have no way to know if it means A or C. It leads to a much more
complicated scheme to ensure that all errors are correctable.
I think formalizing the specification could go a long way and encouraging
alternate implementations is going to be the best way to reduce unexpected
small bugs having a bad effect except on the buggy node.
That being said, it's a huge chicken and egg problem. No one wants to go
off the reference
Mail list logo