Nostr notes by

📅 Original date posted:2014-07-04 📝 Original message:On ...

2023-06-07T17:23:35+02:00

In reply to nevent1q…dz2c
_________________________

📅 Original date posted:2014-07-04
📝 Original message:On Friday 04 July 2014 04:37:26 Gregory Maxwell wrote:

[excellent explanation removed for brevity]

> > Apologies in advance if this is a stupid idea.
>
> No need to be sorry— talking about these things is how people learn.
> While I don't think this idea is good, and I'm even skeptical about
> fixed versions— I promise you many other people were thinking similar
> or even less useful things and will find the discussion interesting.

Thank you for the very thorough and courteous response. I'm sorry that I
suggested something that had been thought of before (seems to be the case on
every great idea I have for Bitcoin) and was not practical; but I'm glad to
have had your response which was certainly educational for me.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-07-04 📝 Original message:On ...

2023-06-07T17:23:34+02:00

In reply to nevent1q…rydr
_________________________

📅 Original date posted:2014-07-04
📝 Original message:On Friday 04 July 2014 07:22:19 Alan Reiner wrote:

> I think you misundersood.... using ROMix-like algorithm, each hash

I did. Sorry.

> requires a different 32 MB of the blockchain. Uniformly distributed
> throughout the blockchain, and no way to predict which 32 MB until you
> have actually executed it. If the difficulty is high enough, your
> miner is likely to end up going through the entire X GB blockchain while
> searching for a good hash, but other nodes will only need to do 32 MB
> worth of disk accesses to verify your answer (and it will be unknown
> which 32 MB until they do the 1,000,000 hash+lookup operations on their
> X GB blockchain).

Excellent.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-07-04 📝 Original message:On ...

2023-06-07T17:23:34+02:00

In reply to nevent1q…nnp3
_________________________

📅 Original date posted:2014-07-04
📝 Original message:On Friday 04 July 2014 06:53:47 Alan Reiner wrote:

> ROMix works by taking N sequential hashes and storing the results into a
> single N*32 byte lookup table. So if N is 1,000,000, you are going to
> compute 1,000,000 and store the results into 32,000,000 sequential bytes
> of RAM. Then you are going to do 1,000,000 lookup operations on that
> table, using the hash of the previous lookup result, to determine the
> location of next lookup (within that 32,000,000 bytes). Assuming a
> strong hash function, this means its impossible to know in advance what
> needs to be available in RAM to lookup, and it's easiest if you simply
> hold all 32,000,000 bytes in RAM.

My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It
wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it
gained you a 1000x advantage over the other miners. It seems that sort of
solution is exactly the one that Mike Hearn was warning against in his blog.

> you'll only be using a small fraction of it for each "hash". This might
> achieve what you're describing without actually requiring the full 20 GB
> of reading on ever hash.

But we want that read. Remember the actual hash rate isn't important, what
matters is how hard it is to reproduce. If we make it 1000x harder to do one
hash for everybody, we're still just as secure. The difficulty adjustment
algorithm ensures blocks come at 10 minutes, regardless of hash rate. So we
can make it harder by picking a harder algorithm -- SCRYPT or BLOWFISH, or
just by upping the size of the data that needs hashing. The advantage of
upping the size of the input is that, unlike an algorithm change, you can't
build a better ASIC to reduce the size.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-07-04 📝 Original message:Hello, ...

2023-06-07T17:23:33+02:00

In reply to nevent1q…g65v
_________________________

📅 Original date posted:2014-07-04
📝 Original message:Hello,

I had a thought after reading Mike Hearn's blog about it being impossible to
have an ASIC-proof proof of work algorithm.

Perhaps I'm being dim, but I thought I'd mention my thought anyway.

It strikes me that he's right that it's impossible for any algorithm to exist
that can't be implemented in an ASIC. However, that's only because it's
trying to pick an algorithm that is CPU bound. You could protect against ASCI
mining (or rather, make it irrelevant that it was being used) by making the
algorithm IO-bound rather than CPU-bound.

For example, what if the proof-of-work hash for a block were no longer just
"hash of block", which contains the hash of the parent block, but instead were
hash of

[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]

[ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and
suffixing the new block, you have to feed every byte of the blockchain through
the hashing engine (the prefix prevents you caching the intermediate result).
Whatever bus you're using to feed your high speed hashing engine, it will
always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and
any hashing engine will, effectively, be the same.

I'm making the assumption that SHA-256 is not cacheable from the middle
outwards, so the whole block-chain _has_ to be transferred for every hash.

Apologies in advance if this is a stupid idea.

Andy
--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-04-24 📝 Original message:On ...

2023-06-07T17:19:27+02:00

In reply to nevent1q…lzje
_________________________

📅 Original date posted:2014-04-24
📝 Original message:On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote:
> > There _are_ consequences though: 95% of the time, you end up buying
> > something and paying for it.
>
> Yeah, I was imagining a situation in which people who use Bitcoin regularly
> do buy things they actually want, but wouldn't say no to occasionally
> getting them for free (think coffees at starbucks etc). So if their double
> spend fails, no big deal, they're no worse off than if they didn't try.

Again true enough; but then we're back to evenly distributed dishonesty, and
so you still don't get the potential 5% scam being used at 100% capacity.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:19:26+02:00

In reply to nevent1q…yz0z
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote:

> OK, sure, let's say most Bitcoin users will be honest (we hope). But
> unfortunately in a situation where fraud is possible users wouldn't
> necessarily distribute evenly over transactions.

That's true, but even in the worst that that 5% hashing power attack means
that 95% of the time, your attack fails. That means you end up paying for
what you bought. Also, you're again changing the comparison basis -- your
CC figures were for the entire industry, not the most badly affected
merchant. You can't say "one particular bitcoin merchant suffers 5% fraud,
therefore that's worse than the 2% fraud averaged across all CC merchants".

> If a merchant is selling something of value repeatedly, then a small
> number of scammers can go back and try their luck over and over. I'm not
> sure how many trades fall into such an exploitable category, though.
>
> Also, there's the philosophical question of how honest people really are
> when there's no consequences to their actions. For instance, if most

There _are_ consequences though: 95% of the time, you end up buying
something and paying for it.

Viewed another way, if I buy something repeatedly from an at risk merchant
(and there won't be many; as you pointed out, mail order is completely
unaffected as you can simply wait for your confirmations) that costs, say
0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free.
Do I really want 100 of them? Even if I do want them, then I've had to
supply capital of 1 BTC to earn 0.05 BTC in kind.

If what I'm buying is another form of money (as with exchanges, or perhaps
casinos) when that "in kind" is just as liquid as the BTC, then fair enough,
there is a risk, but that just incentivises the merchant in those cases to
not allow withdrawal/deposit until 6 confirmations have been received.
Those merchants then move from "at risk" to "not at risk".

I'm still struggling to see how bitcoin could ever be as bad as CC fraud.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2014-04-23 📝 Original message:On ...

2023-06-07T17:19:25+02:00

In reply to nevent1q…t7tr
_________________________

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote:

> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants win
> about 40% of chargeback disputes. So if N was only, say, 5%, and there
> was a large enough population of users who were systematically trying to
> defraud merchants, we'd already be having worse security than magstripe
> credit cards. EMV transactions have loss rates in the noise, so for
> merchants who take those Bitcoin would be dramatically less secure.

Just pedantry: 100% of credit card transactions _can_ be fradulantly charged
back but arent. In fact, only 2% are ever attempted.

If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly
"charged back"; so then why wouldn't only 2% of those bitcoin transactions
be fraudulant too, just as in the CC case?

The comparison would then be 2% chargebacks for credit cards, equivalent to
0.1% (5%*2%) for bitcoin.

Not that I think that makes anything else you say invalid.

Andy
--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2013-10-04 📝 Original message:On ...

2023-06-07T17:07:18+02:00

In reply to nevent1q…qta4
_________________________

📅 Original date posted:2013-10-04
📝 Original message:On Friday 04 October 2013 13:32:47 you wrote:
> > There is more to a git branch than just the overall difference. Every
> > single
> > log message and diff is individually valuable.
>
> When the log messages don't accurately describe the contents of the diff,
> it's just misinformation and noise. Everyone starts out by wanting a neat
> collection of easy to understand and review commits, but in practice it's
> extremely hard to always get it.

Then your request should be for better commits, not for just squashing the lot
into some incoherent blob.

The alternatives under discussion are:

- Coder produces long chain of commits on feature branch. Compresses them,
throwing away any individual and accurate messages into one large diff. It's
unlikely you'll get a log message that is as descriptive in the large one if
you made them throw away the little ones. Large diff is offered for review.
Review is of one large diff.

- Coder produces long chain on commits on feature branch. Offers them for
review. Reviewer only likes to review large diffs, so uses the tools
available to produce it.

Exactly the same diff is being reviewed, but in one case you're throwing away
information. There is no getting that information back ever.

You're also discarding the advantages of individual commits.

- Merges are considerably harder than rebases. You have to resolve all the
conflicts at once with a merge, with a rebase you can resolve them with the
log message and original isolated diff to help you.

- Bisect doesn't give as fine-grained an answer.

> I know how to make squashed commits, thanks. I've done LOTS of code review

Excellent. Don't take it personally -- I only offered it in case you didn't
know. Not everyone is familiar with git plumbing.

> in my life. I'm making a point here as one of the few people who goes
> through large pull requests and reviews them line by line. It's hard,

That doesn't make you the only person who does code reviews. I do plenty of
reviews here; they're just not bitcoin reviews. Obviously we're talking about
bitcoin, so you get to decide in the end.

> partly because github sucks, and partly because reviewing lots of small
> commits sucks.

I'm not suggesting you review lots of small commits anyway. I can't comment
on whether github sucks or not -- that's obviously personal preference.
However, nothing stops you doing reviews on your own local checkout.

> There's nothing that makes a single large commit harder to review. It's the
> same amount of code or strictly less, given the tendency for later commits

That's not true. There are often lots of small changes that are manifestly
correct -- let's use string changes as an example -- in the large commit, they
are just noise. You want to be able to focus on the hard commits. However --
I am not trying to persuade you to review small commits, I'm trying to
persuade you not to throw away the small commits, gone forever, merely because
your preference is to review large commits.

> to change earlier ones. You can easily search the entire change whilst
> reviewing. There are lots of things that make it easier.

Since the large commit is always available, no facilities have been lost.

Personally I work hard in my repositories to make coherent, small, well
described commits. If I had gone to that effort for a bitcoin branch only to
be told to collapse them all and throw away that effort, I'd think I'd been
wasting my time.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2013-10-04 📝 Original message:On ...

2023-06-07T17:07:18+02:00

In reply to nevent1q…3vtq
_________________________

📅 Original date posted:2013-10-04
📝 Original message:On Friday 04 October 2013 12:30:07 Mike Hearn wrote:
> Git makes it easy to fork peoples work off and create long series of
> commits that achieve some useful goal. That's great for many things.
> Unfortunately, code review is not one of those things.
>
> I'd like to make a small request - when submitting large, complex pieces of
> work for review, please either submit it as one giant squashed change, or

Don't do this. It throws away all of the good stuff that git lets you record.
There is more to a git branch than just the overall difference. Every single
log message and diff is individually valuable. It's easy to make a squashed
diff from many little commits; it's impossible to go the other way.

Command line for you so you don't have to think about it:

git diff $(git merge-base master feature-branch) feature-branch

git-merge-base finds the common ancestor between master and feature-branch,
and then compares feature-branch against that.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2013-07-23 📝 Original message:On ...

2023-06-07T17:04:57+02:00

In reply to nevent1q…8xzz
_________________________

📅 Original date posted:2013-07-23
📝 Original message:On Monday 22 July 2013 20:42:45 Jeff Garzik wrote:
> URL: https://github.com/bitcoin/bitcoin/pull/2844
>
> Adding an HTTP REST API for bitcoind has been occasionally tossed
> about as a useful thing. Such an API would essentially provide a
> decentralized block explorer capability, enabling easy external access
> to transaction/address/block indices that we maintain.

This is excellent.

> The first two implemented API calls are simple, returning a block or
> TX given a simple query string based on block hash, e.g.
>
> GET /rest/tx/TX-HASH
> or
> GET /rest/block/BLOCK-HASH

One additional URL makes this pretty much perfect:

GET /rest/block-with-tx/TX-HASH

Construction of the transaction-hash-to-block database is something the full
client's have to do anyway, so this query is no harder than the others for
them to supply; but suddenly makes it possible for an SPV client to trace the
providence of any transaction without needing to maintain the entire chain.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2013-03-13 📝 Original message:On ...

2023-06-07T13:38:58+02:00

In reply to nevent1q…xs34
_________________________

📅 Original date posted:2013-03-13
📝 Original message:On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> Here's a simple proposal to start discussion from...

It seems to me that the biggest failure was not the development of two
chains, but the assurance to users (by the client) that their transactions
were confirmed.

Is it possible to change the definition of "6 confirmations" so that it's
something like: "six confirmations clear of any other chain". While there
are two competing chains, it's possible that one will go pop at any moment.
That makes the confirmation count of any transaction on one of those chains,
zero.

It doesn't seem impossible that clients could be made far more permissive
about acknowledging the existence of blockchains that they wouldn't
necessarily accept themselves (if the proof of work was valid) and warning
the users that it's going on.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2012-06-16 📝 Original message:On ...

2023-06-07T12:15:35+02:00

In reply to nevent1q…yse8
_________________________

📅 Original date posted:2012-06-16
📝 Original message:On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
> As replied on the github issue:
>
> Personally I still think it's better to have a clear standardized
> "protocol version", that implies what capabilities are supported,
> instead of a capability-based system that explicitly lists them.
>
> Capability-based systems (just look at OpenGL) tend to become
> horrendously complex, as you have to take into account all possible
> combinations of possible interactions, and constantly check for support
> of specific features instead of just comparing a version number.
>
> Sure, it can be necessary to distinguish between different types of
> nodes, but there is no need to make it this fine-grained.

It's less of a problem in a (nearly) stateless protocol like Bitcoin.

I like the idea of a capabilities command; as time goes on and the ecosystem
of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
blockchain/memory-pool-query clients becomes more varied, it's going to be
more an more important. The particular example that occurs is thin clients
connecting to the network are going to want to ensure they are connected to
at least one non-thin client.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T04:50:51+02:00

In reply to nevent1q…rgyd
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: Nodes in a network have the option to choose what work to do, and should have a way of forwarding the results of that work to other nodes. Transaction verification is the main one. However, it requires a web of trust as well as a web of connections.
📝 Original message:On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote:
> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > Why should they have to? Joining the network as a node is very low cost
> > to the other nodes. You can't force any node not to be lazy, since
> > their option is to disconnect themselves. As to maliciousness, that is
> > defended against because when a node negative announces a transaction,
> > that transaction is going to be checked (note that there is still no
> > implicit trust) -- if a node is incorrectly negative-announcing then it
> > can justifiably be kicked.
>
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.

Yes; I appreciate that. It's the very point I'm making. A node can choose
what work to do, and should have a way of forwarding the results of that work
to other nodes. Transaction verifification is the main one.

Once a negative-announce message exists, it wouldn't be hard to have the other
two you need as well: positive-announce and neutral-announce. At present we
have only neutral-announce. However, as the need for super nodes and
distributed verification gets bigger, having the forwarder able to offer an
opinion on the quality of a transaction seems ideal to me. Dishonesty will
get you isolated pretty quickly if you use positive-announce and negative-
announce to lie.

The problem with this is that it requires a web of trust as well as a web of
connections. The only way to gain an advantage from this classified
forwarding is if you have some way of assigning enough trust so that you can
forward a classified transaction _without_ checking it yourself. That doesn't
sound like an easy problem though.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/49edfc8b/attachment.sig>;

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T04:50:39+02:00

In reply to nevent1q…xah0
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: A node should not be forced to do any work it doesn't want to, but it should be truthful about the work it chooses to do.
📝 Original message:On 2011 December 22 Thursday, Michael Grønager wrote:

> But, there is in fact a subtle difference: If anyone can choose to verify
> at random, you will see lazy implementations where random means none, and
> as it is random you cannot, from the outside, judge if a node is taking
> part in the validation work or if it just benefitting from others
> announcements. In the hash space part, you can monitor peers and see if
> they did not tell you about a failed validation and then disconnect from
> them as they are either malicious or lazy.

Why should they have to? Joining the network as a node is very low cost to
the other nodes. You can't force any node not to be lazy, since their option
is to disconnect themselves. As to maliciousness, that is defended against
because when a node negative announces a transaction, that transaction is
going to be checked (note that there is still no implicit trust) -- if a node
is incorrectly negative-announcing then it can justifiably be kicked.

> Besides from that, I like a setup where we scream about failed
> verifications, but keep a low profile on things that actually verifies...

Me too. It's important though to distinguish between "you must be verifying"
and "if you do verify, you must be honest about it". No node should be forced
to do any work it doesn't want to; but they should be forced to be truthful
about the work they choose to do.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/c6e7a6da/attachment.sig>;

📅 Original date posted:2011-12-22 🗒️ Summary of this ...

2023-06-07T04:50:32+02:00

In reply to nevent1q…ktrs
_________________________

📅 Original date posted:2011-12-22
🗒️ Summary of this message: A proposal for a hierarchical network where miners/supernodes are tightly interconnected at the top and lightweight clients verify transactions at the bottom.
📝 Original message:On 2011 December 21 Wednesday, Christian Decker wrote:

> Supernodes will be those nodes that verify all transactions and make them
> available to miners. Since miners will become more and more specialized
> these supernodes are likely to be owned by the miners themself. To be a
> miner either you need to verify all the transactions you include (otherwise
> others might be able to find an error in your block and thus drop it) or
> have someone that verifies them for you. In the end I think we'll end up
> with a hierarchical network, with the miners/supernodes tighly
> interconnected at the top and the lightweight clients that simply verify
> transactions (or their inputs to be precise) that are destined for them at
> the bottom.

A thought occurred to me. We already run a decentralised system, but it's
done by making everyone duplicate all other work. There is no fundamental
reason why all work needs to be duplicated though. What about this: every
node randomly chooses whether to verify any particular transaction. If we
assume the network is large and the random factor is correctly chosen, then we
can still guarantee that every transaction is verified. Then, we simply add a
protocol message that is a negative-announce transaction. That is to say, we
give nodes a way of telling other nodes that they think a transaction is
invalid. The other nodes are then free to verify _that_ assertion and forward
the negative-announce.

Miners can then listen for negative-announcements and use them to decide were
to dedicate their verification efforts. They then don't need to verify all
(or perhaps even any) transactions themselves and can dedicate their
processing power to mining.

(I've actually mentioned this idea before, but that time I was using it as a
double-spend prevention method).

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111222/b2825251/attachment.sig>;

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T04:48:13+02:00

In reply to nevent1q…tq6z
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: The IETF does not specify anything in the PATH part of the URI, but it's important to use technology people are already familiar with for usability.
📝 Original message:On Friday 16 Dec 2011 17:41:25 Rick Wesson wrote:
> Its a negative example -- in that the IETF does not specify anything
> in the PATH part of the URI. The scheme, sure, but not in the path,
> there are many types of URI schemes ( start with RFC 2396 )

You seem to have jumped off the topic; you mentioned that there were
thousands of RFCs that we should review over why we shouldn't use a URI; and
you've pointed at an RFC that shows how a URI can be used.

While you're right that CGI and HTTP aren't magic; they are commonplace; and
it's important when we want an infinitely expandable mapping system that
people can use technology they are already familiar with. People already
have web servers, people already understand URIs. It's not "just what we
are used to"; people who can cope with development of the bitcoin protocol
aren't going to be worried about protocol complexity. It is a concern about
what the rest of the world will have to do to get a bitcoin alias.

> Providing a mapping from user at authority.tld addresses usability and

No it doesn't address usability at all, because it falls down on the first
attempt: what if I want to supply a URI that allows my web service to link
an invoice number to an issued bitcoin address? You've forced every mapping
service to be identical, and limited.

> identity. I'd like to see an elegant transformation, specifically I
> take to task anyone that advocates
> https://authority/foo/user?tx=1zhd789632uilos as elegant.

You've been unfair, the equivalent of your "user at authority.tld" is
"https://authority.tld/user"; or "https://user.authority.tld/"; or
"https://google.com/bitcoin/user"; or any of an infinite number of other
variations that _I_ as the mapper get to choose rather than whoever wrote
the BIP; all of which are arguably no less "elegant" than that simple email.

There is no equivalent in the other direction though. For someone who
want's to supply the TX to their mapping server... where does it go in
"user at authority.tld"?

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T04:48:10+02:00

In reply to nevent1q…vg9j
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Using a standard like IIBAN for Bitcoin Payment Routing Address can have a huge public relations benefit and give people a sense of familiarity. However, the ultimate goal is to provide human-readable names for Bitcoin addresses.
📝 Original message:On Friday 16 Dec 2011 19:06:52 Gavin Andresen wrote:

> I think there is also a huge public relations benefit to using a
> standard like IIBAN instead of inventing our own. Having a Bitcoin
> Payment Routing Address (or whatever it ends up being called) that
> looks like the number issues by big financial institutions will give
> people the warm fuzzies.

I can see the PR advantages, but isn't mapping from one massively long,
multi-character, human-opaque number (IBAN) to another (bitcoin address) a
bit of a waste of time?

Surely the point of all this is to provide at least the possibility of a
human-readable name for a bitcoin-address?

Isn't there a possibility that one day we might want to be able to say "send
me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins"? Or
similar?

Andy
--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T04:47:54+02:00

In reply to nevent1q…80lg
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: A discussion on proposals for standard URLs, with one participant suggesting reviewing RFCs for examples of alternative approaches.
📝 Original message:On 2011 December 16 Friday, Rick Wesson wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> wrote:
> > I really like this proposal with standard URLs. All other proposals like
> > DNS mapping or email aliases converted to URLs with some weird logic
> > looks strange to me.
>
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.

Could you point me at an example?

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/017b7ff8/attachment.sig>;

📅 Original date posted:2011-12-15 🗒️ Summary of this ...

2023-06-07T04:47:22+02:00

In reply to nevent1q…qjdp
_________________________

📅 Original date posted:2011-12-15
🗒️ Summary of this message: The BIP15 standard should set the format of the client-server conversation, not the URI format, as interaction is necessary for generating temporary addresses. An aliasing server can give a single, unchanging, well-known label to a transacting party, but still enable that party to generate a new address per transaction. Anonymity is already lost in a supplier-client relationship, and any aliasing scheme necessarily reduces anonymity.
📝 Original message:On 2011 December 15 Thursday, Walter Stanish wrote:

> > Andy sounded very convincing when talking in favor of URLs. What's
> > wrong with his proposal?
>
> A URI identifies a resource and is in effect an alias itself.
> Identifying a resource is different from interacting with it. So,
> while <resource-type>://<resource-type-specific-alias> will work
> sufficiently for the identification, it does not explain the
> interaction.

Quite so; the BIP15 standard shouldn't be setting the format of the URI; it
should be setting what the format of the client-server conversation is.
Effectively, what headers will a requesting client send? What headers should
a server require? What will a server respond?

> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.

I think that's missing the point; any aliasing scheme is definitely reducing
your anonymity, neccessarily so -- the alias has to be looked up somewhere,
that somewhere reduces anonymity. If anonymity is what you want, stick with
just a bitcoin address. The point of an aliasing server is surely to be able
to give a single, unchanging, well known label to a transacting party, but
still enable that party to generate a new address per transaction.

I want my webshop to be able to say "please pay 3.20 BTC to
https://mywebshop.com/payments/orderid=27282"; to enable the automatic
connection from orderid to bitcoin address (which my payment system can then
monitor for payment receipt). (This is just one example).

> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Well yes; but then the client has no idea what address to send to unless it
connects to that URI... interaction/address generation is done when that
connection is made.

In short: I don't really think that this aliasing system should be concerning
itself with preserving anonymity of the receiving party. That is almost
certainly already gone (I'm hardly likely to send money to someone I don't
know unless I like gifting random cash). The sending party loses a little
anonymity because their IP is revealed when they connect to the aliasing
system. But there is very little anonymity in a supplier-client relationship
anyway (you have to say what goods you want, and where you want them, and you
had to interact with a website when you were ordering already).

Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/74e9c385/attachment.sig>;

📅 Original date posted:2011-12-16 🗒️ Summary of this ...

2023-06-07T04:45:26+02:00

In reply to nevent1q…j96y
_________________________

📅 Original date posted:2011-12-16
🗒️ Summary of this message: The use of HTTPS is centralized, but necessary for secure communication. Trust is needed somewhere, and until PGP support is available, CAs are necessary.
📝 Original message:On 2011 December 16 Friday, Rick Wesson wrote:

> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE

HTTPS takes care of that.

> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.

This is the only real problem with HTTPS: we would be centralising part of our
otherwise decentralised system. CAs are certainly a risk.

However, trust is needed somewhere in the communication. There is no way to
securely communicate between A and B without the use of some previously
trusted secure channel -- in Joe Sixpack's case it's by assuming that the
browser he downloaded came with an untainted CA list, and that the CAs are
trustworthy. Neither of which is guaranteed. Until and unless we get PGP
support in browsers, CAs are all that we have.

Worrying about CAs misses the point anyway; if we're being that paranoid --
how did A tell B the appropriate alias to use for a lookup? Was that channel
secure too? I could set up a MITM server that simply looks for the alias
"RICKWESSON at bitcoinaliases.org" and rewrites it to
"ANDYPARKINS at bitcoinaliases.org". When the answer to that problem is HTTPS
(or some other system that requires a previously authorised secure channel for
transfer of trust), then we're back where we started, and HTTPS is acceptable.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/c16ac4b7/attachment.sig>;

📅 Original date posted:2011-12-19 🗒️ Summary of this ...

2023-06-07T04:44:20+02:00

In reply to nevent1q…c35w
_________________________

📅 Original date posted:2011-12-19
🗒️ Summary of this message: HTTPS issues are social, not technical, with multiple CAs being tricked or strong-armed into issuing fake certificates. Bitcoin cannot solve this problem.
📝 Original message:On 2011 December 19 Monday, Jorge Timón wrote:
> Ok, so HTTP is not an option unless it shows a huge warning. I don't
> know the HTTPS possible attack, but maybe it needs a warning message
> too, from what you people are saying. Although using namecoin to

The problems with HTTPS have been social rather than technical. Multiple CAs
have been strong-armed by governments or tricked into issuing fake
certificates by scammers. There is no technical measure around that. By
using the CA certificate we are saying to the system "here is someone I trust
to issue a certificate". So far, with a large number of CAs, that trust is
misplaced.

I'm of the opinion though that this problem is outside the remit of bitcoin to
solve.

Perhaps we should be more strict about which CA certificates are trusted by
the bitcoin client: say restrict it to those who have demonstrably good
practices for verifying identity; rather than the ridiculous amount of trust
that comes pre-installed for me in my browser.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/b557a325/attachment.sig>;

📅 Original date posted:2011-08-10 🗒️ Summary of this ...

2023-06-07T04:14:06+02:00

In reply to nevent1q…rn84
_________________________

📅 Original date posted:2011-08-10
🗒️ Summary of this message: A developer expresses frustration with the negative attitude towards new feature suggestions in an open-source project, suggesting a mentoring approach instead.
📝 Original message:On Wednesday 10 August 2011 19:41:51 Gavin Andresen wrote:
> > To be honest I feel a bit like every change that I (and I've also heard
> > this from others) propose is shot down, no matter how well
> > formulated. This is actively discouraging developers from joining
> > this project.
>
> Well, to be honest I don't think more developers adding new features
> are needed right now-- I think the project's critical needs are more
> people testing and helping to fix bugs and scalability issues.

(Rant follows; stop reading now)

That paragraph reveals a gross misunderstanding of how open source works.

People get itches and they want to scratch them. They aren't paid, so they
don't necessarilly want to turn up and be told which part they _should_ be
working on. The choice is not "bug fix that Gavin wants" or "new feature
that New Developer wants", it is "New Feature" or nothing.

Of course, nothing forces existing developers to accept these new features;
but the incredibly negative attitude on display when any new feature is
suggested is not the way to grow a community. The correct way is a
mentoring attitude -- offering opinions on how a new developer can get their
idea in rather than telling them why it will never happen.

> I don't see how dividing efforts between a 'bug fix' and 'development'
> branch will help fix the project's critical needs. If we did, I think

Again: that's not your call. People will work on what interests them. I've
suggested a couple of features both here and on the forum and been shot down
in varying degrees every time. Fine, but don't expect that I'm thinking
"well I'll become an unpaid bug fixing grunt instead".

I don't expect to be appointed head developer because I suggest an idea. I
don't even expect anyone else to implement my idea for me. But why should I
spend time on my own idea when the feedback is "no", "no", "we've already
thought of that", "not needed", "go away", "why not fix some bugs instead"?

I'm amazed that John Smith is as polite and persistent as he is looking at
the amount of effort he's put in putting a pretty face on the train crash
that existed before hand and seems to get no benefit of the doubt for his
work.

> there would be less pressure to help with the boring bug-fixing and
> testing of the bug-fix branch, which I think would be bad.

That pressure might be relieved if the community were able to grow a bit,
and people felt they had a personal investment. That means loosening the
reigns a bit; and perhaps a development branch would be the way to do that
while not compromising code quality.

I suggest a look at the way git itself is developed; it has the following
branches:

- master: the latest release + newly accepted features
- maint: the latest release + bug fixes only
- next: new features planned for inclusion, actively being worked on.
Often created by merging "topic" branches from individual developers
working on their current itch
- pu: crazy stuff; not planned for inclusion, but acting as a staging
area for people to show what they're working on

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-08-04 🗒️ Summary of this ...

2023-06-07T04:12:11+02:00

In reply to nevent1q…3ajp
_________________________

📅 Original date posted:2011-08-04
🗒️ Summary of this message: A proposal to add a new message type to the Bitcoin network to detect double-spending transactions is met with objections due to increased network traffic.
📝 Original message:On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:

> But why? It results in slightly more network traffic which is exactly
> what we don't want, and it adds yet another message people have to know
> about.

"Slightly" is an understatement. It add more network traffic for every
double spend attempt. Which don't happen very often.

Also, I'm not proposing a new message, heaven forbid that we add a new
message type, I'm proposing that we do this:

enum
{
MSG_TX = 1,
MSG_BLOCK,
+ MSG_DOUBLESPEND,
};

Also, people don't "have" to know about it. And it's not "people" it's an
addition to the _one_ official client. _and_ it's backward compatible
because if they don't know about it, nothing changes... the TX gets dropped
just as it is now.

> > I think you've missed the point. Double spend transactions that enters
> > the network at two reasonably evenly connected points are each only
> > seen by half the network, since the first one locks out the second
> > from propagation.
>
> No one cares about what the network thinks is the right transaction, its
> only what miners believe that matters.

They do care because the network as a whole is what makes the eventual
decision about which is the block-chain-to-rule-them-all. Chain forks, and
eventual reorgs are also far less disruptive when each leg of a double spend
isn't on each potential chain. "Half the network" includes half of the
miners. It's perfectly possible for half the miners to be working on one
leg, half on the other. That means it's 50/50 which leg eventually gets
confirmed.

> Even if the vending machine doesn't keep the full chain and doesn't
> accept incoming connections, its still the target node. What other
> nodes on the network think doesn't matter as long as you get the target
> to think a transaction that won't be confirmed will be. If it doesn't
> accept incoming connections you want to find nodes that do that are
> connected to your target.

Well that's true enough; but how on earth you're going to identify an IP
address of a particular vending machine that isn't accepting incoming
connections is beyond me. If it is a target it's pretty close to invisible.

> Its much easier to create than to change the network code to relay info
> on double-spend transactions.

What? It's easier to trigger massive adoption and organisation of an
inherently disorgainsed network of miners than it is to write a few lines of
code? If that's true, then the bitcoin source is even more impenetrable
than I imagine.

> > Well that's what happens now. But that doesn't help the poor sap who's
> > just handed over some goods. I want it so that small businesses can
> > use the client to give them practical answers instead of this
> > "0/unconfirmed" stuff which requires understanding of the system.
>
> No, thats not what happens now. Currently if your node gets a
> transaction which conflicts with one it already knows about, it silently
> drops it without a second thought. My point is if you actually dealt
> with such cases and made good connections, you would be able to prevent
> double spends nearly perfectly.

It's not about prevention, they are already prevented. It's about
detection. Quickly.

> > I'm not really trying to prevent double spends -- bitcoin _already_
> > prevents double spends. Also: the only difference between your
> > suggestion (don't drop) and my suggestion (don't drop but mark with
> > MSG_DOUBLESPEND) is a single number in the inv. I really don't get
> > the objection.
>
> No, my suggestion is not to relay the second transaction. The second
> transaction should continue to not be relayed as it currently is,
> however receiving such a transaction should trigger the node to notify
> the user that the transaction should not be accepted until it makes it
> into a block (in fact, you could already do this if you implemented a
> debug.log parser and made well-placed connections).

How is this second transaction going to end up anywhere but on a few
isolated nodes if it isn't propagated? The only way _both_ can be in a pool
is if they are both received. If they aren't both forwarded then it won't
be in most pools. If it isn't in most pools then which how is the relevant
user going to get notified?

> Bitcoin is absolutely still an experiment and no one thinks that any
> kind of future is guaranteed. This was not meant as an argument, but

If it's still an experiment why is there such huge objection to pretty much
every change anyone proposes? Bitcoin is one of the most conservative
projects I've ever seen, even for the most passive of changes. I can
understand wanting to prevent potential financial loss, but it's not like
I'm suggesting we start broadcasting private keys on the network.

> simply as "if bitcoin does end up going somewhere, it will likely be
> done like this".

When you're using it as an argument for why a suggestion is unnecessary
that's not how it sounds.

Anyway; it's fine. You don't think it's a good idea; and I suspect none of
the other official client developers will either, they don't like protocol
changes. So be it; it was only a suggestion and I'm a nobody around here.

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-08-04 🗒️ Summary of this ...

2023-06-07T04:12:05+02:00

In reply to nevent1q…pc8k
_________________________

📅 Original date posted:2011-08-04
🗒️ Summary of this message: The discussion is about adding an extra type to the inventory list to prevent double-spending in Bitcoin transactions, making it easier for small businesses to use the client.
📝 Original message:On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> There really is no reason to add the extra network complexity for this.

It's hardly complex. It's exactly as it is now, with exactly the messages
there are now, but with an extra type added to the inventory list. A
transaction _already_ propagates using inv messages with MSG_TX, is it
really so "complex" to add MSG_DOUBLESPEND to the enum? What's more it's
backward compatible because clients that don't understand MSG_DOUBLESPEND
will ignore the inv ending up exactly where we are now.

> First of all (as you point out) no one buying a Ferrari will refuse to
> wait an hour for the payment to confirm. If someone is attempting to
> pull a similar trick on, say, a vending machine however it might make
> sense. But that changes the equation. In order for these two scammers

Vending machine, newspaper salesman, ice creams, a beer. The list of small
vendors is endless. I picked Ferrari's out of the air.

> to pull it off, some effort is required in terms of communicating the
> time to send the coins and the nodes of the targets (vending machines or
> whatever) must be figured out. So now its less of "make it impossible"
> and more of "make it really hard to the point that it is no where near
> worth the effort".

I think you've missed the point. Double spend transactions that enters the
network at two reasonably evenly connected points are each only seen by half
the network, since the first one locks out the second from propagation.

> Lets simplify the scenario a bit so that one scammer can pull it off.
> Send one copy of your transaction to the target node and another to
> large mining operations so that the payment transaction is considered
> invalid to miners and a transaction which pays you is confirmed.

There is no "target" node. There is only a vending machine listening for
transactions. It's unlikely that vending machines will even have incoming
connections enabled. They certainly won't be keeping a full copy of the
block chain or be mining.

> If you are the vending machine, your goal is not to figure out any
> transactions which are yours, but to figure out which transactions which

It is a little bit. Your job is _first_ to figure out which are yours;
then, as you say, to see which are going to be confirmed. Well: once you've
seen a transaction on the net you know it's going to be confirmed... unless
a matching double spend transaction was accepted by the next miner to
generate a block.

> are yours are going to be confirmed. So, you peer with the largest
> miners (a "Bitcoin backbone" or large miners and merchants has been
> suggested over and over again and really hasn't happened) and modify

It hasn't happened, and yet it seems to be that this non-existant thing is
your solution to the problem.

> your client to, instead of dropping transactions which are
> double-spends, keep both in memory pool and consider them both invalid
> until one of them confirms.

Well that's what happens now. But that doesn't help the poor sap who's just
handed over some goods. I want it so that small businesses can use the
client to give them practical answers instead of this "0/unconfirmed" stuff
which requires understanding of the system.

> This will work with 1, 2, or n scammers, doesn't require any additional
> network messages, and offers just as good, if not better security over a
> double spend message.

I'm not really trying to prevent double spends -- bitcoin _already_ prevents
double spends. Also: the only difference between your suggestion (don't
drop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a
single number in the inv. I really don't get the objection.

> Additionally, in the future, when(/if) Bitcoin payment processors exist,

"In the future" is all well and good. What if there is no future because
bitcoin is still too difficult for average joe to use?

Andy

--
Dr Andy Parkins
andyparkins at gmail.com

📅 Original date posted:2011-08-04 🗒️ Summary of this ...

2023-06-07T04:11:58+02:00

In reply to nevent1q…ws6a
_________________________

📅 Original date posted:2011-08-04
🗒️ Summary of this message: A proposal to solve the issue of double-spending in Bitcoin transactions by broadcasting a "MSG_DOUBLESPEND" message when a transaction is dropped.
📝 Original message:Hello,

Here's a scenario (it's contrived to make the players easy to identify, more
likely this would be low value automated vendors):

Two scammers get together to buy two Ferraris using only one set of BTC. They
travel to opposite ends of the world to two car dealerships that accept
bitcoins without waiting for confirmations. They are in contact by mobile.
They each buy the car and come to pay. At exactly the same moment, they both
spend the same coins. They both walk away with a car.

The current solution is the recommendation that vendors wait for six
confirmations before releasing goods. That's a long time though; more than
most would be willing to wait.

Some points:
- The bitcoin network is essentially honest
- If a block chain fork happens, the transactions that are orphaned get added
to the pending transaction list again, meaning ...
- A valid transaction will _eventually_ make it into the (longest) block
chain.
- Actual distribution time for a transaction through the network is in the
order of seconds not minutes
- A double spend attempt has to enter the network near simulateously at
different places, otherwise the second spend will be rejected instantly by
the whole network.

New transactions propagate through the network if they are found to be valid.
If they aren't valid, they are silently dropped. In the event of a double
spend attempt one of those transactions goes to (say) half the network, the
other goes to the other half. Whichever one reaches a node first is seen as
the real one, the second being seen as invalid. One or other of these will
therefore end up in the "longest" chain; but there is no way to know which.

Here's my proposal then: when a node drops a transaction, it should not be
silent. It should be broadcast just as it always was going to be had it been
valid. Only it is broadcast with a new "inv" type, let's say
"MSG_DOUBLESPEND" instead of "MSG_TX".

Now run the Ferrari test again. The vendor sees the transaction that pays for
the car appear near instantly (within the propagation time of the network). A
short while later they also see a MSG_DOUBLESPEND of the same coins that they
have just accepted. They can then operate whatever policy they want: wait for
six, ten, twenty confirmations. Call the police. Whatever. Miners can also
significantly lower the priority of any transactions that get flagged in this
way.

When there isn't a double spend attempt message within the network propagation
time, they can be sure that their transaction is the one that miners are
working on, and they'll eventually get their money. In other words, they can
accept the payment on zero confirmations.

At first I was concerned that this would make it possible to DOS a
transaction, but of course it doesn't -- the transaction has to be internally-
valid to result in a MSG_DOUBLESPEND, meaning it can only be DOSed by someone
with the appropriate private keys.

Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110804/00d1be22/attachment.sig>;