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 referenc
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.
Scrubbing A,
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
spending my c
doing it was laziness in just creating a single key.
On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr wrote:
> On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> > This was one of my concerns when implementing a scheme where you sign a
> > refund transaction before the origi
, 2013 at 8:27 PM, Luke-Jr 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 also would prefer to go straight to uBTC as the "standard wallet unit".
It works out perfectly with Satoshi's being the decimal units. Something
that costs $10USD would be 25000uBTC. This isn't a problem for a place
like South Korea, where 10USD is about 10,000 Won, so we aren't even off on
a
to be
> 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 Piscit
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 wrote:
> To piggyback on Jeff,
>
> Any proposal that is going to add reliance upon data from third parties
> outside of the Bitcoin network itself is like
Ryan,
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 wrote:
> I think you misunderstood
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 wrote:
> You just completely ignored my point. I'm not sure who's trying to insult
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.
For example, Alic
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.
https://bitcointalk.org/index.php?topic=260898.10
I haven't gone back to see if there are any ways around it, but the main
problem here is I need the Contract
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
n
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 most
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,
it seem
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
such a m
The worst 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.
-Allen
On Thu, Mar 27, 2014 at 11:06 AM, Pavol Rusnak wrote:
> On 03/27/2014 04:57 PM, Alle
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,
then so
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 wrote:
> On the Chinese "Single's Day" (sort of like the american Black Friday)
> according to MIT's Tech Review
>
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
adapt to.
On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
wrote:
> -BEGIN P
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
on altru
/12/2015 07:47 PM, Allen Piscitello wrote:
> > 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
If I had a time locked signed transaction where I threw away the key, this
would potentially invalidate my transaction.
What is the point of such a rule?
On Wed, Apr 15, 2015 at 6:43 PM, s7r wrote:
> Hi,
>
> Would it be wise to add a consensus rule like the one we have for blocks,
>
> (if > 75%
What prevents you from writing a bad check using today's systems?
On Tue, May 26, 2015 at 1:22 PM, 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 t
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 wrote:
> Trust, regulation, law, and the threat of force. Are you serious?
> On 26 May 2015 11:38 am, Allen Piscitello
> wrote:
>
> What pr
26 matches
Mail list logo
