Andy Parkins [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-07 to 2014-07-04
💬 Posted a total of 76 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv

Profile Code

nprofile1qqsfn0kyjaegepywv42f6xjj2lggm6tky8kukjmhquexnfza43cg6kg0ulv4f

Author Public Key

npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv

Show more details

Last Notes

2023-06-07 15:23:35

- reply

📅 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

2023-06-07 15:23:34

- reply

📅 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

2023-06-07 15:23:34

- reply

📅 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

2023-06-07 15:23:33

- reply

📅 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

2023-06-07 15:19:27

- reply

📅 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

2023-06-07 15:19:26

- reply

📅 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

2023-06-07 15:19:25

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday 23 Apr 2014 12:07:25 Mike Hearn wrote:
> > Just pedantry: 100% of credit card transactions _can_ be fradulantly
> > charged
> > back but arent.
>
> If you do a chargeback the bank double checks this, investigates it and
> people who repeatedly try and do fraudulent chargebacks get their
> accounts terminated. It's not like your bank offers you a "reverse this
> payment" button in the UI that always works, right?
True; the effort of a chargeback is non-zero on credit cards; but that's my
point: it's non-zero for bitcoin too.
> > 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?
>
> If you attempt fraud against a bank, they know who you are and will come
> after you in one way or another. But it's safe to assume that users of a
> double spend service would be anonymous and the kind of merchants they go
> after are not hassling their customers with strong ID checks, so there
> would be no consequences for them. It's a game they can only win.
You're still being unfair to bitcoin. Not everyone who uses bitcoins will
be dishonest. The dishonest 5% hashing power is not going to be used in
100% of any given merchants transactions. That's all I'm saying. You're
original statement that we could end up in a position that bitcoin has a
higher failure rate than credit cards seems unfair to me.
> 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.
"[If] there was a large enough population" -- why are bitcoin users more
dishonest than credit card users? Most people are honest, so it seems
unlikely that that 5% attack surface would be used at 100%; or even 40%
necessary to equal the 2% chargeback rate with CC.
I really didn't want to get into an argument over this: all I'm saying is
that things aren't as bad as you painted them.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:19:25

- reply

📅 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

2023-06-07 15:07:20

- reply

📅 Original date posted:2013-10-04
📝 Original message:On Friday 04 October 2013 07:35:17 you wrote:
> Remember that every individual commit is two things: what source code
> has changed, and a message explaining why you thought that change should
> be made. Commits aren't valuable in of themselves, they're valuable
> because they serve to explain to the other people you are working with
> why you thought a change should be made. Sometimes it makes sense to
Yes -- I'm assuming that. I'm not advocating creating commits with random
data as a log, and random bits of the changes.
> explain your changes in 10 commits, sometimes it makes sense to squash
> them all up into one commit, but there's no hard and fast rule other
> than "Put yourself in your fellow coders' shoes - what's the best way to
> explain to them what you are trying to accomplish and why?" You may have
> generated a lot of little commits in the process of creating your patch
> that tell a story that no-one else cares about, or equally by squashing
They don't care _now_; but when it comes to finding bugs, I can't count the
number of times having a detailed change history has helped. Combined with
git-blame, it makes it very easy to ask "why did this line go in?".
> everything into one big commit you wind up with a tonne of changes with
> little explanation as to why they were made.
True enough. I'm happy to accept that what you want is "the most optimum" set
of commits. But that doesn't mean "squash it all together".
> Two caveats apply however: git-bisect works best if every commit in the
> tree you are trying to debug works well enough that you can run tests
> without errors - that is you don't "break the build". Don't make commits
> that don't compile at the very least, and preferably everything you do
> should be refactored to the point where the commit as a whole "works".
Absolutely true. I'm in favour of having the CI system test every commit for
exactly that reason. Even if you don't do that though, simply making the
effort to make commits coherent means that its rare to get commits that don't
build.
> FWIW personally I tend to review patches by both looking at the
> individual commits to try to understand why someone wanted to make a
> change, as well as all commits merged into one diff for a "what actually
> changed here?" review.
I think that code review is fundamentally hard. There is only so much you can
do to make it easier; and I'm not sure encouraging contributors to squash
their chains is it. Encouraging better commit behaviour would be better.
However, I'm only a lurker, not a committer, weight my opinions accordingly.
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/20131004/cde9187b/attachment.sig>

2023-06-07 15:07:18

- reply

📅 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

2023-06-07 15:07:18

- reply

📅 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

2023-06-07 15:05:00

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tuesday 23 July 2013 11:17:28 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
> > > Increasing the resource usage by SPV clients on full nodes is
> > > undesirable;
> >
> > I don't think that's thinking big enough. What I imagine is that making
> > it easier and easier to store a partial blockchain would result in lower
> > demand on full nodes.
>
> Read my proposal for "Partial UTXO" mode:
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02
> 511.html
Very interesting. I love the idea of the UTXO set being tied to a block.
> > I might run a client that has only fetched blocks that contain
> > transactions needed to verify my balances, right back to the genesis
> > block. That will be some small subset of the block chain and will take
> > me very little resource to maintain. I join the network and am my
> > client is willing to verify based on information I have, or supply (by
> > REST or bitcoin protocol) blocks. Imagine then that everyone with a
> > wallet were doing this. The blockchain would be distributed massively.
> > Obviously the miners would still be keeping the entire chain, but we'd
> > have a lot more nodes in the network, each contributing a little bit and
> > so reducing the load on the full nodes.
>
> Actually the really scary thing about partial UTXO mode is miners can
> get away without keeping the entire chain provided they don't (often)
> try to mine transactions spending UTXO's that they haven't verified
> themselves.
You're right. That is scary.
> > > In any case UTXO data currently requires you to have full trust in
> > > whomever is providing you with it, and that situation will continue
> > > until UTXO commitments are implemented - if they are implemented.
> >
> > Almost; because you can go and ask someone else the same question, it's
> > pretty
>
> How do you know they actually are someone else?
You don't. You can't invalidate the lie if all you have access to is lies.
But if you have access to just one honest node; that will reveal the liars.
I'm not claiming that headers-only nodes can ever be made as secure as a full
node. Just _more_ secure than they are now; and potentially able to act as
one of those honest nodes.
> > easy to check if you're being lied to. Also, it's far easier to maintain
> > a headers-only block chain. When you fetch your relevant block subset,
> > you can easily see that they are real blocks in your headers-only
> > blockchain; and so it's pretty much impossible to lie to "give me the
> > block containing transaction X".
>
> Do you think you have SPV or full security in that situation?
> Do you know the difference?
There is absolutely no need to get condescendingly shirty. I thought this was
a friendly list; and we were having a discussion. If you don't want to
respond to posts -- don't. I also didn't realise I had to pass an exam before
I was allowed to speak.
Yes: I know the difference between SPV and full security. SPV is headers only
and so has no way to verify that the transaction outputs references as inputs
to any new as-yet-unverified transaction are valid. Instead it relies on
having some way of proving it's in the chain; and then looking for the number
of blocks built on top of it as "verification". "Full security" (which is
itself a very poor name), is obviously just checking that every output
referenced in the inputs is unspent; that necessarily requires full blocks.
The difference in security being that in SPV there is no way to know if the
referenced Unspent TransaXtion Output really is unspent -- it might have been
spent elsewhere then referenced again in this new transaction.
My suggestion was that we want to be able to fetch a block by transaction; and
that simple nodes can all, in aggregate offer contribution to the network
rather than just being parasitical on the full nodes. When I ask for a block
that contains a transaction, and I do that repeatedly, I have part of the
block chain. If lots of simple nodes are doing that, then the whole chain
should be available if there are enough of them. They would then gain the
ability to do transaction-forwarding in some cases. This is only possible if
a few extra facilities are added to the protocol. One of which is the new
feature I suggested: block-given-transaction. It's not enough on its own, but
if you also add in the ability for a node to tell another about the output
transactions (basically, what block spends it), _then_ the simple nodes are
able to become much more secure -- not 100% of course, they're still not full
nodes, because they have no way of knowing if they are being lied to when they
are told (this transaction is unspent), but all it takes is one honest node to
point them at the truth, and the lie is then exposed.
That facility is just a drain on full nodes for the most part; except if you
start encouraging it whole-sale. The simple node would keep cache both the
incoming and outgoing transactions (or rather the blocks that contain them)
for addresses to which they are paying attention. That gives them a cache
that contains more than just their minimal set; and then they are able to do
just a little bit of verifying on their own. With enough nodes of this sort,
the verification load is reduced.
Perhaps all that effort is not worth it for the tiny reduction. Perhaps it's
not true that that contribution of verification adds nothing. I can live with
those objections. But "do I know the difference" as a reposte? Not so much.
Anyway; going by your post on partial UTXO's; you're well ahead of the game,
and I'm not suggesting anything that hasn't already been thought of, and
thought of better. I'm not sure why you took umbridge at my idea, when it
seems like I'm just a few steps behind what you've already thought of. Not
everything is an attack you know?
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:04:59

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > 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.
> The REST API has nothing to do with SPV clients; it's similar to the RPC
> interface and won't be exposed to the network as a whole.
Yes; I know that. I'm saying that it would make it easier for SPV (and other
lightweight clients) for that matter.
> Increasing the resource usage by SPV clients on full nodes is undesirable;
I don't think that's thinking big enough. What I imagine is that making it
easier and easier to store a partial blockchain would result in lower demand
on full nodes.
I might run a client that has only fetched blocks that contain transactions
needed to verify my balances, right back to the genesis block. That will be
some small subset of the block chain and will take me very little resource to
maintain. I join the network and am my client is willing to verify based on
information I have, or supply (by REST or bitcoin protocol) blocks. Imagine
then that everyone with a wallet were doing this. The blockchain would be
distributed massively. Obviously the miners would still be keeping the entire
chain, but we'd have a lot more nodes in the network, each contributing a
little bit and so reducing the load on the full nodes.
> In any case UTXO data currently requires you to have full trust in
> whomever is providing you with it, and that situation will continue
> until UTXO commitments are implemented - if they are implemented.
Almost; because you can go and ask someone else the same question, it's pretty
easy to check if you're being lied to. Also, it's far easier to maintain a
headers-only block chain. When you fetch your relevant block subset, you can
easily see that they are real blocks in your headers-only blockchain; and so
it's pretty much impossible to lie to "give me the block containing
transaction X".
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:04:58

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tuesday 23 July 2013 10:42:05 Pieter Wuille wrote:
> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
> > 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.
>
> There is actually no such index being maintained by default, and doing so
> is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to
> get this). Of course, if enabled, it can be exposed.
Wow. I'm surprised at that. How does a newly received transaction have its
inputs verified then? Multiple linear brute force searches of the block chain
for every new transaction? Or is it that transactions are only recorded if
they were in a block, and just their presence indicates they're valid?
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:04:58

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tuesday 23 July 2013 10:56:02 Pieter Wuille wrote:
> The block chain is not involved at all to verify transactions, it's
> just a historical
> record to serve to other nodes, and to do wallet rescans with.
It must be involved to some extent. Certainly during a temporary fork, there
are two branches growing, and you have to be able, when verifying a new
transaction, to say which branch it's one... which branch of the blockchain.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:04:57

- reply

📅 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

2023-06-07 15:02:34

- reply

📅 Original date posted:2013-05-31
📝 Original message:On Friday 31 May 2013 12:56:43 Rune Kjær Svendsen wrote:
> I have an application that wants to keep up with new blocks as they come
> in. For that I can use the -blocknotify option with bitcoind, which will
> execute my application for each new block.
>
> The problem is that my app isn't necessarily quick enough to finish its
> work before a new block comes in and the app is executed again. This means
> the that bitcoind might keep executing my application even though the
> previous instance hasn't finished, and that's fairly inefficient
> resource-wise, as many instances of the application will be running
> simultaneously.
Have your program try to create a unix-domain socket when it starts. If it
can't create it (because one already exists at that path), then connect to it.
You then have two modes:
- Creator of socket, listens to socket for more incoming data, and adds it to
some sort of internal block queue.
- Client to socket, pushes output of -blocknotify to socket and exits
Your concurrency problems go away because only one process is ever actually
doing something with the data.
Should be fairly straight forward. The client is simple. The server is two
threads, one listening on the socket and then briefly locking and updating a
queue, and one thread briefly locking and removing from the queue.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:01:13

- reply

📅 Original date posted:2013-05-01
📝 Original message:On Wednesday 01 May 2013 15:26:57 Jeff Garzik wrote:
> A generalized HTTP REST query protocol would be a nice addition... it
> is just off-topic for this thread. On IRC yesterday, we discussed an
> HTTP query interface like you suggested. It was agreed that it was a
> nice interface, and might be a nice addition to bitcoind.
>
> That is a separate topic for a separate email thread, though.
>
> As an example, see the pull request I wrote for an HTTP REST interface
> that downloads an encrypted wallet backup:
> https://github.com/bitcoin/bitcoin/pull/1982
Fair enough.
I'm usually behind the state-of-the-art when I suggest things here :-) I
should just trust you guys have already planned everything I might think of.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 15:01:12

- reply

📅 Original date posted:2013-05-01
📝 Original message:On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote:
> Hardly. The storage format is bitcoin protocol wire format, plus a
> tiny header. It is supported in multiple applications already, and is
> the most efficient storage format for bitcoin protocol blocks.
"Most efficient" for what purpose? There is more that one might do than just
duplicate bitcoind exactly. I can well imagine storing bitcoin blocks parsed
and separated out into database fields.
> > Wouldn't it be better to add support for more bitcoin-protocol-oriented
> > HTTP requests? Then any client can supply the same interface, rather
> > than being forced to create blkNNNN.dat on the fly?
>
> You don't have to create anything on the fly, if you store blocks in
> their native P2P wire protocol format.
If. What if I'm writing a client and don't want to store them the way
bitcoind has?
> This is a whole new client interface. It's fun to dream this up, but
> it is far outside the scope of an efficient HTTP protocol that
> downloads blocks.
Except the alternative is no schema at all -- essentially it's just give
access to a file on disk. Well, that hardly needs discussion at all, and it
hardly needs the involvement of bitcoind, apache could do it right now.
> Your proposal is closer to a full P2P rewrite over HTTP (or a proxy
> thereof).
I don't think it's a "rewrite". The wire protocol is only a small part of
what bitcoind does. Adding another thread listening for HTTP requests at the
same time as on 8333 for stadnard format.
Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol
was, and it's not like I was volunteering to do any of the work ;-)
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 14:56:23

- reply

2023-06-07 14:56:22

- reply

2023-06-07 11:45:41

- reply

📅 Original date posted:2013-04-10
📝 Original message:On Tuesday 09 April 2013 22:03:35 Mike Hearn wrote:
> To get bitcoinj 0.8, check out our source from git and then run *git fetch
> --all; git checkout **cbbb1a2bf4d1*. This will place you on the 0.8 release
> in a secure manner. This message was written on Tuesday 9th April 2013 and
Not quite secure yet, because you didn't sign your email.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 11:38:58

- reply

📅 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

2023-06-07 10:45:23

- reply

📅 Original date posted:2012-12-04
📝 Original message:On Monday 03 December 2012 11:19:37 Michael Gronager wrote:
> The aged coins are simply included in the block mining reward, creating
> another incentive for miners. Further, if we include all coins in this
> recycle scheme coins will never be lost forever.
Ignoring the cost of storing these never-spent outputs; there is absolutely no
reason we need to ensure that coins aren't lost. Nor worry about those that
are.
The total bitcoins produced is an entirely arbitrary number -- a function of
the 210,000 halving rate and the initial block reward. Satoshi could have
picked anything for them and bitcoin would work exactly the same.
Lost coins never enter the economy ever again, and so supply is slightly lower
than it would have been, making all the non-lost coins worth ever so slightly
more. Effectively: price adjustments will take care of lost coins.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 10:41:26

- reply

📅 Original date posted:2012-11-27
📝 Original message:On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:
> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce an invoice with the right security
> bits.
That's good; I've not done anything with protocol buffers, so wasn't aware it
was that simple.
> > In particular two additional identification types:
> > - GnuPG (obviously)
>
> It's not obvious to me, incidentally. The web of trust has been
> dead-on-arrival since it was first proposed, and for good reasons.
> SSL/X.509, for better or worse, has significant usage.
Sorry, I meant "obviously" in the sense that "obviously that's the other one
that everyone will want". The web-of-trust as a universal identity mechanism
is, I agree, not useful. However, as a localised, smaller-scale identity
verification system it's used by every GnuPG user. You become your own
certificate authority. For example, I've set up my whole family with GnuPG;
I've set them up to trust me to authenticate (and I doubt any of them has ever
added anyone else). Then I take on the responsibility of signing all my
family/friends keys and they don't need to worry about it.
There's no reason that a small group of companies wouldn't do exactly the same
sort of thing.
> Your case of a small business is a perfect example of people who won't
> be using GPG. If they don't want to buy an SSL cert, they can just as
Bear in mind, I was using that example as an example of a hash protected in a
GPG envelope, not a GPG-signed invoice. People who've already got their GPG
system in place will appreciate being able to leverage it.
> well put a reference number in the memo field or a "Hey Bob, here is
> the bill we discussed". The payer does not get the multi-factor auth
How can they put a hash of an invoice inside the invoice? In my "hash mode"
invoices, it would be a random number (or possibly specifying the hash
algorithm) then the SignedInvoice would simply be the original invoice + hash.
That hash would then be reported via some secure channel outside of bitcoin's
domain.
> protection so if their computer has a virus, they may be hosed. But
> that's good incentive for sellers to get verified. Some CA authorities
> do it for free these days.
I don't understand what the relevance of multi-factor is to invoices? The
payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or
not? This invoice system has one primary job: to ensure that the target of
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 10:41:20

- reply

📅 Original date posted:2012-11-27
📝 Original message:On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
Personally, I'd like to see fewer implicit ties to X509. With X509 as one
option. For example, I'd much prefer to see a doorway to the future left open
like this:
message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;
or similar, instead of "x509chain".
In particular two additional identification types:
- GnuPG (obviously)
- Hash based
The hash-based system would be there as a method of leveraging an existing
trusted connection, without needing to get into the nitty-gritty of
certificates. For example, I am paying for something on a web site; I
presumably already have a secure connection that I trust to that site. That
site can issue me an invoice (which is to be sent to the bitcoin client) _and_
a hash of the certificate on the same page.
I trust that hash because I received it over a secure connection from a
trusted source. When my bitcoin client pops up with the received invoice, it
shows me the hash of the invoice, and I can be sure that it is from the web
site I thought it was from.
Imagine I'm a (very) small business, I have two or three customers. I want to
email one of my customers an invoice. I don't want to have to get an X509
certificate, and I don't necessarily know how. However, I can ring my
customer up and say "I've generated an invoice with my bitcoin client, it is
hashed A7DE-521X-9977. Write that down and confirm it when you get my
invoice". Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 10:19:27

- reply

📅 Original date posted:2012-06-27
📝 Original message:On 2012 June 26 Tuesday, Pieter Wuille wrote:
> Additionally, such addresses are exchanged and relayed via the P2P network.
> To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in
Yuck. Can't we pinch a few of the addr.services bits to store an address
family? AF_INET, AF_INET6, AF_CUSTOM_TOR, and leave space for a few more
would be, say, four bits out of 64 mostly unused.
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/20120627/00ea91b2/attachment.sig>

2023-06-07 10:15:58

- reply

📅 Original date posted:2012-06-16
📝 Original message:On Saturday 16 Jun 2012 02:34:53 Amir Taaki wrote:
> Introspection/command discovery is nice, but I would prefer it to be
> immediately done in the first version exchange so no assumptions as to
> how a network is operating need to be made.
That would need a change of the current version message. So why not make
the change be simply: one of the service bits indicates that "getcmds" is
available?
Then the version message doesn't need any on-the-wire change.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 10:15:45

- reply

📅 Original date posted:2012-06-16
📝 Original message:On Saturday 16 Jun 2012 09:42:21 Wladimir wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and
> offers (at a certain version level), without having to explicitly
> enumerate everything over the protocol.
My problem is that that I suspect the spectrum of clients will be far more
than simply "thin" or "thick". What about thick-pruned, thick-full? What
about thin-blocks-on-demand and thin-headers-on-demand? These are just what
I can think of now; it seems unwise to limit the functionality of clients
not yet designed with a binary designation. So... we make a field that can
hold more than just a bit; with each possible value representing a specific
(possibly overlapping) set of features? Why not just enumerate the features
then?
I did write responses to each of your following points; but they just
sounded like me being contrary. The short version is that I think too much
emphasis is being placed on defining a specific set of feature->version
mapping. That's going to make it hard for future clients that want to
implement some of the features but not all, and yet still want to be good
bitcoin citizens and be able to tell their peers what they don't support.
For example, there is no easy way for a node to tell another that it doesn't
have the whole block chain available, so requesting it from it will fail.
> I'm just afraid that the currently simple P2P protocol will turn into a
> zoo of complicated (and potentially buggy/insecure) interactions.
Fair enough.
> So maybe a capability system is a good idea but then the granularity
> should be large, not command-level. The interaction between protocol
> versions and capabilities needs to be defined as well. Does offering
> "getdata" at protocol version 10 mean the same as offering it at
> protocol version 11"? Probably not guaranteed. The arguments might have
> changed. So it's not entirely self-documenting either.
That problem doesn't go away just because you don't have a capabilities
system. Either version 11 can speak version 10 or it can't. I don't see
how having a system for finding out that fact changes anything other than
removing a load of protocol noise.
"I support getdata10" makes it far easier to discover that the peer supports
getdata10 than sending getdata11 and watching it fail does.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 10:15:35

- reply

📅 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

2023-06-07 10:04:07

- reply

📅 Original date posted:2012-04-13
📝 Original message:On 2012 April 12 Thursday, Jeff Garzik wrote:
> One of my From-Day-One complaints about bitcoin is that transactions
> behavior could be far more deterministic (predictable), from a user
> standpoint. Transactions in the current system can easily remain in
> limbo forever.
>
> One big step in making transactions behave more predictably would be
> to remove transactions from the memory pool, if they have not made it
> into a block for a couple days. i.e.
A change I've wished for for a while (but I suspect it is too big a change to
ever make it) is that a transaction announcement include the block the user
wants to base on. It would only be in the protocol message, not the
transaction stored in the blockchain.
The advantage is that (1) it protects against double spends without needing a
confirmation period; as a merchant I can instantly spend a 1-confirmation
transaction by creating my transaction with that 1-confirm as its "base". (2)
your expiry from memory pool becomes easy -- if the "base" is more than N
blocks below the current head, then that transaction won't be included.
Retransmission is possible with the base updated.
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/20120413/d9e35fe5/attachment.sig>

2023-06-07 03:02:48

- reply

📅 Original date posted:2012-02-01
📝 Original message:On 2012 January 31 Tuesday, Andy Parkins wrote:
> - Increase the version number in transactions to make a new transaction
> structure
> - Dump the "scriptPubKey" field completely. Everything will be pay-to-
> script-hash in version2 transactions
> - Replace it with "hashOfClaimingScript"
> - Add an "unsignedParameters" array.
Having thought about it; I've realised that the above is simply BIP16 without
the backward compatibility work in it. If BIP16 renamed the scriptPubKey
field to "hashOfClaimingScript" and no longer ran it as a script, it woudl be
close to identical. We'd simply define the field as
0xa9 0x14 <hashOfClaimingScript> 0x87
Detection of this format of scriptPubKey activates "version2" processing of
the transaction. And similarly, a new definition of scriptSig to be two
fields:
unsignedInitialStackBlock
scriptClaim
I'm sure nobody cares about my opinion; but that's actually been the moment
of epiphany for me (and I raise it here, in case it is for someone else).
Having previously been against BIP16, I'm now happy with BIP16 -- it's a
progression towards the ideal... having a literal claimScriptHash field
instead of scriptPubKey; and never running scriptPubKey.
Potentially OP_CHECKSIG could be simplified as well because the rules could
be "anything that's not the serialized script" in scriptSig is not signed.
I can imagine one day, when the network is all BIP16 compliant, that
scriptPubKey will no longer be allowed to run as script at all.
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/20120201/c2cd486b/attachment.sig>

2023-06-07 03:02:44

- reply

📅 Original date posted:2012-02-01
📝 Original message:On 2012 February 01 Wednesday, Pieter Wuille wrote:
> > old clients won't they? They don't pass IsStandard().
>
> IsStandard() is for accepting transactions into the memory pool.
> Non-standard transactions are verified just fine when they are in the block
> chain.
Ah. My misunderstanding then.
> If we do a breaking change to the protocol - such as adding a new
> transaction type - ALL users must upgrade. Those who don't will see a fork
> of the chain from before the first new-style transaction. That is not the
> case now.
That makes a big difference. Thanks for the correction.
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/20120201/a82fe52c/attachment.sig>

2023-06-07 03:02:38

- reply

📅 Original date posted:2012-02-01
📝 Original message:On 2012 January 31 Tuesday, Luke-Jr wrote:
> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being
Is that true? (I'm happy to be called wrong)
It doesn't seem like it to me. The new transaction types will be rejected by
old clients won't they? They don't pass IsStandard().
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/20120201/bde45eae/attachment.sig>

2023-06-07 03:02:35

- reply

📅 Original date posted:2012-02-01
📝 Original message:On 2012 January 31 Tuesday, Gregory Maxwell wrote:
> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.
Well that's good that there is no real problem.
> It does not, in fact— Yes, it requires a client update to make use of
> the new functionality, but old nodes will happily continue to validate
> things. It's hard to express how critical this is distinctly.
> Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that
> things were done right, the validate them for themselves.
>
> A breaking change of the kind you suggest is not something that would
> be considered lightly, and this is certainly not justified for this.
To be brutally honest; I don't see how the BIP16/17 changes are any less
"breaking" than what I proposed (I'm not trying to push mine; forget it, the
last thing bitcoin needs is another proposal if there is no real argument).
I will agree the changes are smaller for BIP16, since the transactions are
left as they are.
If BIP16/BIP17 were being honest they would too increase the version number
of the transaction structure. The new transaction type is not supported by
the old client... that's a break. My argument would be that once you're
going to break the old clients anyway, go the whole hog and fix some other
stuff as well.
> If we ever were to scrap the system, I think we very much would do
> something like what you describe here... and as much has been
> documented:
>
> https://en.bitcoin.it/wiki/Hardfork_Wishlist
> (see "Elimination of output scripts")
I'm glad I wasn't talking rubbish then.
> But, to be clear, this stuff is pretty much fantasy. I'm doubtful that
> it will ever happen, doubtful that we can get the kind of development
Me too. Which is a shame; as it means we're locked into quite a fair number
of earlier decisions that will now never be changed.
> resources required to pull off a true breaking change in a way that
> people would actually trust upgrading to— at least not before a time
> that the system is simply too big to make that kind of change.
Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm
just not familiar enough with the conventions. As far as I understand; no
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not
going to pass the IsStandard() test.
I'd repeat: the reasonable thing to do is to increase the version number of
the transaction structure to indicate that they are being processed
differently from old transactions.
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/20120201/1fd55c20/attachment.sig>

2023-06-07 03:02:26

- reply

📅 Original date posted:2012-01-31
📝 Original message:On 2012 January 31 Tuesday, Luke-Jr wrote:
> I'm not aware of any remaining *tangible* objections to BIP 17 at this
> point (Gavin seems concerned over a theoretical
> risk-that-nobody-has-thought-of), but if there's a better solution, I'm
> perfectly fine Withdrawing BIP 17 to support it.
I imagine the BIP16 supporters would say the same? Isn't that the essence of
the current impasse?
> Both BIP 16 and 17 are backward compatible enough that people can continue
> to use the old clients with each other. An upgrade is only required to
> send to (or create/receive on) the new 3...-form addresses. That being
> said, it's quite possible to rewrite the practical implications of both
> BIP 16 and 17 in the format you seem to be suggesting. Doing so would even
> get rid of one of the major objections to BIP 16 (its inconsistency).
My suggestion is backward compatible. You'd only have to make version2
transactions for version2 addresses; and the join between version1 and
version2 is not a problem since the version1 source can be detected, and the
handling of the version2 transaction altered as appropriate (it's only a
matter of switching from the hash check to running the two scripts as
normal).
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/20120131/0908135b/attachment.sig>

2023-06-07 03:02:20

- reply

📅 Original date posted:2012-01-31
📝 Original message:Hello,
Gulp. Am a little nervous about wading into this swamp. However, it seems
to me that the debate has veered into the personal and away from the
technical. Surely if there are objections to both suggestions, that another
solution might be better? The answer doesn't have to be A or B, if the
answer C turns out to be acceptable.
That being said; I am not confident enough to start making BIPs so I offer
this idea up for my traditional mailing-list roasting but with the hope that
I blindly stumble toward something more acceptable to everyone.
----
If the change is going to be a big one anyway and will require a client
upgrade why not...
- Increase the version number in transactions to make a new transaction
structure
- Dump the "scriptPubKey" field completely. Everything will be pay-to-
script-hash in version2 transactions
- Replace it with "hashOfClaimingScript"
- Add an "unsignedParameters" array.
hashOfClaimingScript is _not_ script. It's just the hash of the script that
is allowed to claim the output. Then before scriptSig is allowed to run, it
is hashed and compared against the hashOfClaimingScript.
unsignedParameters replaces the need for all the crazy messing around that
OP_CHECKSIG currently does because it is specifically a block of the
transaction that it not signed (although I would include the array size bytes
in the signature calculation), therefore no script filtering is necessary.
The claiming script, scriptSig, can then be checked against whatever list of
templates you like. For pay-to-address it will probably look like:
OP_PUSHPARAMETER {0}
OP_PUSH { <claimant public key> }
OP_CHECKSIGVERIFY
Handling the more complicated transactions (they're the point of all this
after all) is pretty obvious; the unsignedParameters block can hold as many
signatures as you like. It also removes the need for OP_CHECKMULTISIG, since
the script can specify the signature conditions. e.g. a 2-of-3 script:
OP_PUSHPARMETER {0}
OP_PUSH { <claimant public key0> }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { <claimant public key1> }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { <claimant public key1> }
OP_CHECKSIG
OP_ADD
OP_ADD
OP_PUSH {1}
OP_GREATERTHAN
(I'm sure someone cleverer than I can improve on the above)
-----
Let the flaming commence...
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/20120131/b2ee00aa/attachment.sig>

2023-06-07 02:58:27

- reply

📅 Original date posted:2012-01-30
📝 Original message:On 2012 January 28 Saturday, Michael Gronager wrote:
> If we want more information in a bitcoin address we could just as well
> cannibalize it from the checksum - today it is 4 bytes (1 to 4mia) it
> could be 2 or 3 bytes (1 to 65k or 16M) and that would not break the
> current meaning of the network ID. This would have the same effect - that
> you could not mistake two different addresses and create a non-redeemable
> transaction.
I'm throwing this out as an idea; not necessarily saying it's doable or even
good.
There is spare capacity in the base58 encoding.
- The address hash is 20 bytes
- The checksum is 4 bytes
- The address type is 1 byte
The longest and largest address is therefore 25 bytes of 0xff (it's not
possible to all be 0xff of course). Converting those 25 bytes of 0xff to
base58...
hex: ffffffffffffffffffffffffffffffffffffffffffffffffff
base58: 2mXR4oJkmBdJMxhBGQGb96gQ88xUzxLFyG
This is 34 base58 symbols. It's not the largest base 58 number that will fit
in 34 symbols though...
base58: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
hex: 20a8469deca6b5a6d367cbc0907d07e6a5584778de27ffffffff
vs hex: ffffffffffffffffffffffffffffffffffffffffffffffffff
i.e. there are a few unused bits (~5) available in the base58 representation
that can be added without changing the number of symbols in the address.
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/20120130/18318a15/attachment.sig>

2023-06-07 02:51:48

- reply

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Amir Taaki suggests using a hierarchical method for mapping browser information, making it easier to scan all browsers using WebKit.
📝 Original message:On 2011 December 21 Wednesday, Amir Taaki wrote:
> In the original intention for BIP_0014, that would map to:
>
> /Gecko:20110613/Firefox:6.0a2/Mozilla:5.0/
>
> With something like WebKit, it becomes easy to see why that would be
> useful. You can suddenly do a network wide scan of all browsers using
> WebKit, rather than having to maintain a database of all WebKit enabled
> browsers.
This seems excellent to me.
I think most developers want to do the right thing when it comes to standards,
and it is only the inflexibility or ambiguity of a standard that means they
don't.
This heirarchical method lets every client supply all the information they
have -- nobody has to make a decision to leave something out. The internal
debate they would have "is my gui version more important than my protocol
engine version?" is unnecessary.
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/20111221/c7b379b6/attachment.sig>

2023-06-07 02:51:20

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: A developer is working on a client that downloads block chain headers and block bodies on demand for full verification, slotting between headers-only and full clients.
📝 Original message:On Sunday 18 Dec 2011 01:27:10 Jordan Mack wrote:
> I don't like the idea of a header only client, unless this is just an
> interim action until the full block chain is downloaded in the
> background. Development of these types of clients is probably
> inevitable, but I believe that this breaks the most fundamental aspects
> of Bitcoin's security model. If a client has only headers, it cannot do
> full verification, and it is trusting the data from random anonymous
> peers.
I'm working on (slowly) making a client able to download-on-demand. That is
to say that the block chain headers would be downloaded and maintained, but
the block bodies would be downloaded as needed for full verification. It's
certainly not possible with the current protocol; but it's certainly a
conceivable application. I suppose it slots between headers-only and full
client conceptually.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:50:51

- reply

📅 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>

2023-06-07 02:50:39

- reply

📅 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>

2023-06-07 02:50:32

- reply

📅 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>

2023-06-07 02:48:13

- reply

📅 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

2023-06-07 02:48:10

- reply

📅 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

2023-06-07 02:47:54

- reply

📅 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>

2023-06-07 02:47:22

- reply

📅 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>

2023-06-07 02:46:28

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Amir Taaki proposes a HTTPS service for Bitcoin aliases, but Dr. Andy Parkins suggests using URLs instead of hard-coded mappings.
📝 Original message:On 2011 December 13 Tuesday, Amir Taaki wrote:
> Maybe I wasn't clear enough in the document, but this is the intent with
> the HTTPS proposal.
I don't like the idea of a hard-coded mapping at all. We shouldn't be making
choices on behalf of server operators. It's up to them how they arrange their
domain names and paths.
I also agree that DNS is not the technology to use. DNS is a nightmare.
> genjix at foo.org
>
> Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
> responds with a bitcoin address. Whether the system gives you a new
> address from a pool of addresses, or contacts the merchant behind the
> scenes is implementation defined.
>
> I'll clarify it later. This is the relevant line:
>
> string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> pszEncodedNick;
>
> Between HTTPS service and server service, I lean slightly towards HTTPS
> (automatic encrypted connection, CAs + all benefits of DNS). But still
> interested in arguments in favour of a server service (daemon answering
> queries).
Why bother with an encoding scheme at all? If the address
genjix at foo.org
always maps to
https://foo.org/bitcoin-alias/?handle=genjix
Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and
"?handle=" and the original email-looking "genjix at foo.org". Just use the URL.
Then the author of the service can use whatever they want.
"Can I pay you 10 BTC?"
"Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"
While I might implement my alias server like this:
"Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
"Sure, send it to 'https://parkins.co.uk/"
... or any other URL they want -- any of which suit might suit me and my
webserver better than whatever mapping would otherwise be hard-coded. The
world is already very familiar with URLs so this is no more scary than the
email address. What's more, the email address form looks _too much_ like an
email address, and will only lead to confusion ... "send it to genjix at foo.org"
"so I use outlook express for that, right?" "erm, no, you put it in your
bitcoin client".
The URL form could easily be made to detect a browser connecting rather than a
bitcoin client (and this is an area that would benefit from a standards
document -- define the headers and user agent triggers that an alias server
expects) and give them better instructions.
https can be specified as the default, so "https://" can be optional when
they're typing. If, in the future, bitcoin gets a distributed peer-to-peer
alias system, then a new URL type can be added easily "bcalias://andyparkins"
might automatically find my node in the network and query it for an address
(or whatever).
All of the above is exactly why OpenID chose to use URLs for ID.
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/20111213/bac47699/attachment.sig>

2023-06-07 02:45:26

- reply

📅 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>

2023-06-07 02:44:20

- reply

📅 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>

2023-06-07 02:42:54

- reply

📅 Original date posted:2011-12-09
🗒️ Summary of this message: Bitcoin transactions can be rejected if a previous transaction is reversed, but it can get tricky with hosted wallets. Explicit block dependencies can prevent financial connections without a bitcoin-connection. Hosted wallets should keep each account as separate public keys.
📝 Original message:On 2011 December 08 Thursday, Stefan Thomas wrote:
> Bitcoin already does something which in practice has exactly this
> effect: If a transaction is reversed, any transactions based on its
> outputs are rejected.
That part is fine; I was aware that Bitcoin did this. How could it not? The
transactions form multiple signature chains of their own. It impossible to
have a transaction depend on a non-existent input transaction.
> Hosted wallets can make use of this - but as you correctly point out,
> depending on the service, it can get tricky. What if I exchange the
> money to USD and back before withdrawing? You could have an algorithm
> where MtGox prefers to spend outputs from your own deposits as the
> inputs for your withdrawals, it's not trivial though and never 100% secure.
Quite so; this is essentially the problem my suggestion addresses. What do
you do when a transaction is dependent on another transaction financially but
not technically? That is to say that your accounting software would show a
credit and a debit to a particular entity, but the bitcoin block chain would
not. In the old world we might do this as "I'll write you a cheque and you
give me cash"; if that cheque bounces, you've lost your cash.
> I have trouble thinking of a good example where you need an explicit
> block dependency as you describe. The only times you'd want to use this
> dependency of transactions on specific previous transactions is when you
> can clearly and easily associate the money. But if you can clearly and
> easily associate the money, you might as well just relate the
> transactions (use the outputs from the deposit transaction as the inputs
> of the withdrawal transaction.)
The MyBitcoin debacle (if we are to believe their reports) would have been
avoided by my suggestion. They were accepting deposits in one chain, and
allowing withdrawls from another. That meant that while there was a financial
connection, there was not a bitcoin-connection. The withdrawls happened from
the pool address, most likely well funded, so were valid on either chain. If
MyBitcoin had been able to broadcast the withdrawl transactions as being based
on the same chain as the deposit (even though it was not using transactions in
that chain) then the attack would have failed.
> This is btw something that would strongly agree with: Hosted wallets
> should absolutely keep each account as separate public keys. With that
> you lose free and instant internal transactions, but you gain instant
> deposits and much better risk isolation.
I'm not sure I agree. There is certainly a case for both types: one-to-one
correspondence between address and account has the advantages you list but is
highly identifiable and trackable. However the disadvantage is that all funds
would have to be kept online. Places like Mt.Gox can (although there is
evidence to suggest that they don't, tut tu) move the majority of the funds to
five USB sticks, and keep them in five fire-proof safes or deposit boxes or
whatever only because deposited funds are pooled.
> This is just my view. Thanks and keep the thought-provoking stuff coming!
Thanks for the encouragement. It's appreciated.
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/20111209/5a680498/attachment.sig>

2023-06-07 02:42:48

- reply

📅 Original date posted:2011-12-08
🗒️ Summary of this message: A proposal to include the hash of the block a transaction wants to appear after, called the basis block, to prevent loss from an attacker's reorganization.
📝 Original message:Hello,
Another of my crazy ideas:
When a transaction is first broadcast, it should include the hash of the block
it wants to appear after, let's call it's basis block. That block can be
anything the claimer wants; but it allows the miners to add this condition:
the transactions outputs a new transaction claims must be before the new
transaction's basis block.
Consider this block chain fork:
* -- * -- F -- * -- 1 -- 4 -- 5
\
* -- 2 -- 3
Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
pooled-account online wallet). In block 1 I transfer credit from address A to
address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
The chain at 3 races out first, but eventually the chain at 5 becomes "the
one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
nothing to stop that same withdrawl making it into 4 (since it comes from a
pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
must wait for six confirmations of 2 before allowing use of the funds. That
is an inconvenience for all the honest users.
With my proposed change, the Mt.Gox transaction broadcast at 3 would include
"block 2" as its basis block. Therefore that transaction could never make it
into block 4, as no miner will include a transaction based on block 2 in the
block 4 chain.
Mt.Gox is probably not a good example, as they have problems with fiat to deal
with too. However, for other online wallet accounts it would allow faster
acceptance of received funds, since there is no danger of loss should an
attacker arrange a reorganisation.
This basis block would be optional (implied by the input transactions if it
isn't present); and would only need storing for the pending transactions, so
no incompatible change is needed to the block format.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:41:43

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: A miner can cheat the timestamp by hashing the block for two more minutes than others, but it risks rejection by peers. The network clock is not part of the protocol.
📝 Original message:On 2011 November 23 Wednesday, Jorge Timón wrote:
> Well, I meant "the probability of your block being the hardest".
> What a miner can do is hash the block (cheating the timestamp) for 2
> more minutes than the rest of the people and then send it to the other
> nodes. Nodes cannot possibly know when did you hashed the block only
> by looking at their clock when they receive it, because there's also
> network latency.
True enough; but then the same is true for everyone else. If the window is 2
minutes after the stated time, then everyone _can_ wait until the end of that
window. However, they risk their block being rejected by their peers, and
their efforts are wasted. In fact, it can be guaranteed by making the accept
window zero. There is then no reason to carry on computing after the reward
window closes, since you know your peers will reject it.
> > (2) For the network clock; see util.cpp:GetAdjustedTime().
>
> 1) This is part of the satoshi client but not the protocol. A miner
> can rewrite this part of the code and there won't be anything in the
> chain that contradicts the protocol.
Well yes. What does that matter? It's only a way of calculating an average
time. The node can use any clock it wants, as long as the block time is
verified by the peers.
> 2) I haven't read the code but I'm pretty sure that's not a perfect
> decentralized clock.
It definitely isn't. NTP is mentioned in the source as an alternative.
> I will be more specific. Where's the network clock in the chain (in
> the protocol)?
It's nothing to do with the protocol; it's an individual miner choosing
whether to accept or reject a block based on the timestamp it claims, and the
current time as the miner sees it. For the sake of compatibility, the clients
currently choose to use a community clock as "current", as established from
the time they receive from peers in the "version" message (it actually holds
offsets between them, which is pretty bad, as a long-connected client will
drift). They don't have to, but if miners aren't using time that approximates
what their peers are using, under my system, their blocks would be rejected:
so an incentive to use that "community clock" exists.
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/20111123/aa9881ec/attachment.sig>

2023-06-07 02:41:36

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: The probability of mining a block is 100% in the proposed system, and the probability of a block being the hardest requires actual hashing power. The network clock is in util.cpp:GetAdjustedTime(). Miners have an incentive to lie about the time, but nodes have an incentive to reject mistimed blocks. The proposed system also prevents an attack that is possible with current bitcoin: recalculating the entire chain.
📝 Original message:On 2011 November 23 Wednesday, Jorge Timón wrote:
> With the current system, the timestamp can also be cheated, but miners
> have no direct incentive to do it. With your system, they increase
> their probability of mining a block by putting a false timestamp.
> Also, where's the network clock you're talking about? Isn't it the
> timestamps in the blockchain?
(1) The "probability of mining a block" is old-think. The probability of
mining a block is 100% in my system. Instead, it becomes "the probability of
your block being the hardest" and that requires actual hashing power
regardless of the timestamp you write on the block. I could write that my
block was generated next year; but I can't fake the hashing power it needs to
generate one year's worth of hashes.
If chain difficulty were summed correctly (sum(log(difficulty)), I guess),
then time makes not the slightest difference anyway. You can issue blocks at
any time with any difficulty, and the "hardest" chain always wins. The block
period can be anything, and it is only the block reward that makes it
necessary to pick a particular period for block issuing (even that could be
worked around I guess with a variable reward, but why bother?).
(2) For the network clock; see util.cpp:GetAdjustedTime().
(3) Current clients do have an incentive: more time. The more time they get,
the more hashes they can try. The current client already checks the
timestamp:
main.cpp:CBlock::CheckBlock()
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
My suggestion only requires that the two hour window be reduced; and a lower
limit to be added. Also: while the miners have an incentive to lie about the
time, the nodes they broadcast to have an incentive to reject mistimed blocks,
so you won't gain much by lying to your peers since your block won't be
accepted -- the incentive is therefore removed.
Note: my system also prevents an attack that is possible with current bitcoin:
recalculating the entire chain. Let's say Visa want to take over bitcoin.
They buy enough computing power to significantly beat the current bitcoin
network; then they start recalculating the entire block chain; since early
blocks were low difficulty, it's not that hard to do. Once they overtake the
real chain, they have effectively undone all previous transactions. (I'm not
suggesting this is likely; and it's actually mitigated by the hard-coded block
hashes). The point is that blocks are only generatable for the time when the
rest of the network is willing to add them to the chain.
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/20111123/c91e1106/attachment.sig>

2023-06-07 02:41:33

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: A proposal to create a "hardest chain" by forking the blockchain and creating simpler blocks on top of an old block, which could allow the revocation of all transactions and claim all the mined coins since the forked block. The difficulty of invalidating a chain is not reduced with a time window approach, as hashes are hashes, and a higher difficulty beats a lower difficulty, making the chain more secure.
📝 Original message:On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
>
> - Pick any old block
> - Create a chain fork by creating simpler blocks on top of your chosen
> one
> - The chain will not be accepted by others
> - At some point you might find an incredibly hard block that makes your
> forked chain the hardest one in the network
> - Suddenly all your blocks are valid and you force people to switch to
> your forked chain
>
> If this is possible it would allow you to revoke all transactions and claim
> all the mined coins since you forked. My point is that the notion of
> hardest chain is not so simple.
The above is a problem in either system (mine or current). If I can make a
"hardest chain", then I have indeed reverted all the existing transactions.
Look at CBlock::AddToBlockIndex(),
if (pindexNew->bnChainWork > bnBestChainWork)
if (!SetBestChain(txdb, pindexNew))
return false;
If the received block has higher total chain work than the current best chain
work; then the new block becomes the head of the best chain. The chain work
being calculated like this (I've abbreviated for the email):
pindexNew->bnChainWork = pprev->bnChainWork + pindexNew->GetBlockWork()
I'm not entirely convinced that this method of totalling chain work is the
best (it's a sum of exponentials I think); but that's a different issue.
> The difficulty of invalidating a chain is dramatically reduced with your
> time window approach, by not requiring a given difficulty, and relying on
> synchronized time windows.
I don't see that it is reduced; it is the same. Hashes are hashes. A given
difficulty isn't required, but a higher difficulty beats a lower difficulty.
So whatever the hashing power of the network at that moment, it's used. That
makes the chain more secure, not less.
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/20111123/270594a5/attachment.sig>

2023-06-07 02:41:27

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: Bitcoin's "I got lucky" block-finding problem is not an issue because the difficulty target is used to compute chain difficulty, not actual hashes found.
📝 Original message:On 2011 November 23 Wednesday, Gavin Andresen wrote:
> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.
Good points. I don't think I have a response to that one.
I saw the "I got lucky" result as a benefit, as it made it harder to fork the
chain. We got an advantage from the luck.
I'll have to abandon this suggestion. It's not going to work.
Thanks for the feedback everyone.
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/20111123/b3a137b0/attachment.sig>

2023-06-07 02:41:14

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: The author proposes a change to Bitcoin's block generation process, suggesting that block difficulty be viewed as a measure of time, not time itself.
📝 Original message:On 2011 November 23 Wednesday, Christian Decker wrote:
> The current block generation with a fixed difficulty was chosen because it
> it clear when to adjust and to what target difficulty it has to be
> adjusted. If we were to use synchronized time windows and select the
> hardest block it gets incredibly complicated as synchronization is not
> possible in distributed systems. Even the smallest drift would allow for
> forks in the chain all over the place. Furthermore the delay in propagation
> will also cause forks.
>
> If 1/2 of the network see one block as the hardest, and for the rest of the
> network it came too late then we'll have a fork that stays with us quite a
> while.
>
> The block chain is described as a timestamp server in the paper, but it is
> more of a proof-of-existence before, as the contained timestamp cannot be
> trusted anyway.
These are reasonable objections. My counter is this:
Let's view block difficulty as a measure of time, not time itself. The
timestamp is merely a convenience for the block. You cannot fake the
computing power needed for a particular difficulty; so the hardest chain
always wins (note: hardest chain).
If I am a miner, I have two choices:
(a) try to replace the top block on the current hardest chain
(b) try to append to the current hardest chain
Either of these is acceptable; but in case (a) I have to generate a more
difficult block to replace it; in case (b), at the start of the window, any
difficulty is acceptable (however, I'm competing with other miners, so _any_
difficulty won't beat them).
The rule then is that you're trying to win the one block reward that is
available every 10 minutes; and your peers will be rejecting blocks with
timestamps that are lies.
Perhaps an example...
- I (a node), download the blockchain
- The blockchain has N potential heads. Each of those heads has a time, t
and a sum_of_difficulty.
- The next block reward is going to go to the highest difficulty with
t < timestamp < (t + T) _and_ verified timestamp (i.e. not received more
than, say 5 minutes, from its claimed timestamp).
- I can choose any head to start generating from, but given that it's the
highest difficulty chain that's going to win the next reward (not the
highest difficulty block), I will surely pick the most difficult?
- A rogue miner then issues a block with a fake timestamp; it actually
generated at (t + T + 5) but claims (t + 5). Should I start using
that block as my new head? Obviously not, because my peers might decide
that it is a lie and reject it because it was received too late, making my
work useless. It is in my interest to pick a head that is honest.
Resolving forks is easy:
- 50 coins every ten minutes only
- most difficult chain wins
I'm certainly not saying it's a simple change. There are certainly areas I
haven't thought about, and could be game-overs; but I do like the idea of
there being no target difficulty, and instead the blocks are issued at a fixed
ten minute rate (or rather the rewards are).
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/20111123/7405827f/attachment.sig>

2023-06-07 02:41:04

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: Nodes generate the most difficult block they can, while listening for the most difficult block generated before time T, with T being the block generation rate.
📝 Original message:On 2011 November 23 Wednesday, Jorge Timón wrote:
> 2011/11/23, Andy Parkins <andyparkins at gmail.com>:
> > Let's abandon the idea of a target difficulty. Instead, every node just
> >
> > generates the most difficulty block it can. Simultaneously, every node
> > is listening for "the most difficult block generated before time T";
> > with T being
> > picked to be the block generation rate (10 minutes).
>
> A miner could try to obtain more difficulty out of time and cheat its
> reported datetime (T).
Just as with the current system.
The defence is that on receipt of a block, its timestamp is checked against
the node's own clock and averaged network clock. Blocks out of that band are
rejected.
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/20111123/87748873/attachment.sig>

2023-06-07 02:40:58

- reply

📅 Original date posted:2011-11-23
🗒️ Summary of this message: A proposal to normalize the block generation rate in Bitcoin by having every node generate the most difficult block it can, without a target difficulty.
📝 Original message:Hello,
One problem with Bitcoin is that if large numbers of miners suddenly switch
off, the network takes a long time to adapt (since the adaption time is a
function of blocks generated, and the block generation rate has changed). The
same problem exists in the other direction, but an increased generation rate
for a little while doesn't really do any harm.
I had this idea as a way of completely normalising the block generation rate,
regardless of network power. I hesitate to offer it, as I get shouted down a
lot, but what the hell...
Let's imagine that the whole network shares a clock (which it does already).
Let's abandon the idea of a target difficulty. Instead, every node just
generates the most difficulty block it can. Simultaneously, every node is
listening for "the most difficult block generated before time T"; with T being
picked to be the block generation rate (10 minutes).
Every node is therefore generating blocks and comparing not against some
moving average determined target, but rather against the most difficult
recently received block. If the generated block is harder than the received
block, then it gets broadcast.
Clearly, early on in the block, the traffic would be high, but that could be
limited with a bit of intelligence -- there's no point broadcasting your best
blocks in minute 0 of the current block... you know everyone will beat it, as
it was so easy. So the rule would be broadcasts only start at T/2 plus a
little randomisation. There wouldn't be that many because someone will have
generated a pretty good block by chance in the first half, and that will
quickly stop anybody else from bothering to broadcast their easier block.
There is no advantage to broadcasting a lesser block, so there is no incentive
to cheat.
As always: the most difficult chain wins; and blocks with out-of-bounds times
are rejected regardless of difficulty. Everyone therefore has an incentive to
base their next block on the block with highest difficulty from the previous
period.
The block period is now guaranteed to be 10 minutes (or in fact, whatever
period you like, there is no danger at all in changing it to 2 minutes); and
there is no change of block generation rate with network power. Changes in
network power merely adjust the average difficulty of the best block per
period. The cost is higher network traffic, because there are block
broadcasts that don't necessarily make it to the end. However, there's no
need to broadcast the full block, only the header. If that block turns out to
be the winner, then the other nodes will request the full block at the end of
the period, and will check it's valid. If it's not then the next highest on
the list will be requested. So again,
I recognise that this is a pretty large change to make; and so don't really
expect it to happen. Perhaps one day though... when all the wishlist items go
into one huge protocol overhaul.
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/20111123/3a6d159f/attachment.sig>

2023-06-07 02:15:38

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: Discussion on Bitcoin transaction filtering and sequence numbers for replacing transactions. Complexities of contracts and the usefulness of picking different source inputs debated.
📝 Original message:On Thursday 11 August 2011 17:17:23 Mike Hearn wrote:
> This thread is getting off-topic so I changed the subject.
Fair enough.
> > The benefit I'm aiming at is to imagine a thin client that has done a
> > fast startup and only downloaded the headers.
>
> OK. A better way is tx filtering, as discussed here:
>
> http://bitcointalk.org/?topic=7972.0
>
> The reason is you want to only get the transactions+merkle branches
> relevant to you, otherwise cost is still O(system activity) not O(your
> activity) as blocks get bigger, even if you don't download every
> block.
Well okay; it seems to me that that is considerably bigger task, and I'm not
sure how likely that is to appear. But that sounds workable, since my
feature request is simply this filtering system with the filter set to
"ALL"; so I can hardly complain about that.
> > The sequence number (and perhaps I've misunderstood) allows me to
> > replace a transaction I've already submitted
>
> Yes, but it's more complex than that.
... good stuff removed for brevity ...
> sequence number than mine - so we establish a kind of chain. Nobody
> can rewind the transaction to an earlier point, but anyone can update
> it within the parameters established by the SIGHASH flags on the
> others signatures.
I can't say I see what the point of all that added complexity is, contracts
are usually more than just financial, and the ability to pick a slightly
different set of source inputs doesn't seem like a hugely useful feature;
but I'm willing to accept someone thinks it is a good idea and leave it at
that. I withdraw my "move sequence number" feature request.
> You can't change anything about the inputs beyond scripts this way.
> The transaction still has to connect to the same outputs as before,
> and thus import the same amount of value.
What then allows the contract out of the memory pool into a chain? The
locktime? No, no, forget it... I don't want to open a new can of worms.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:14:42

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: Mike Hearn explains that it is normal for project maintainers to say "no" more often than they say "yes" in open source projects. He also clarifies that ideas which receive "maybe" or "yes but later" or "no unless you convince me" or "perhaps in a different way" are not being shot down, but rather requests for more work to be done.
📝 Original message:On 2011 August 11 Thursday, Mike Hearn wrote:
> I don't think Gavin misunderstands how open source works at all. It's
> completely normal for project maintainers to say "no" more often than
> they say "yes". When I worked on open source for a living this was
> part of the natural flow of things.
That wasn't the part I said he didn't understand. It was assuming that you
can just declare that people should work on bug fixes and not features was a
misunderstanding. People work on open source (at least at first) to get a
feature they want. They aren't just going to show up and cry "command me
lord".
> It's important to understand that ideas which receive "maybe" or "yes
> but later" or "no unless you convince me" or "perhaps in a different
> way" are not being shot down. These answers are requests for more work
> to be done. You *cannot* get emotional about open source contributions
> and any veteran will tell you this. Open source maintainers cannot and
> do not say yes to every patch or idea that is proposed. I would be
> very worried if Gavin did.
I don't expect them to; as I said, I'm not after everything I say being
accepted out of hand, certainly as I haven't even turned up with patches. And
you are absolutely correct that that would be worrying if it were so. What I
object to is no guidance is offered to get the suggester what they want, a
"you could have this if you did it like this", or "perhaps if you explained a
bit more". It's just "no, your idea is based on your weak understanding of
bitcoin," perhaps I'm being overly arrogant, but I think I understand it a lot
more than you presume I do.
I do try not to get emotional about these things; and email is not the best
medium for conveying level of distress -- I'm certainly not banging on my
keyboard, close to a heart attack. My motivation is only that I would like to
see bitcoin do well, and I do see that the treatment of potential new people,
while not offensive (nobody says f*ck off), is not encouraging.
> Now let's review these ideas:
Honestly you needn't have bothered. They've been reviewed to death at this
point; and I'm not that interested in fighting to get them into a project that
doesn't want them. I'll just play with my bricks over in the corner if that's
okay? I offered the list as a demonstration that ideas don't get constructive
help as to how progress can be made on them (i.e. how to make them
acceptable), they just get rejected.
Anyway; as you've put the time in, I'll do the same and respond.
> > Don't believe me? Here's a list of ideas
> >
> > - Extra bits in the service field of the version message to allow nodes
> > to indicate if they are mining; if they are willing to be seed nodes;
> > if they relay transactions; if they want relayed transactions.
>
> I think the concept is reasonable but service flags might not be the
> best way to do it, for instance, asking for a filtered transaction
> feed is useful for lightweight clients so you'd want more precision
> that can be fit into service bits.
The service bits just seemed like the "bitcoin way" as the field already
existed. Personally I would prefer an additional "capabilities" request with
a variable number of ASCII strings in it, each indicating a capability, and if
that's good with all of you -- excellent.
> > - getblocks in reverse chronological order so clients can start up
> > quicker while downloading the blocks in the backround. Ironically I was
> > told "patches welcome" by someone who didn't reject this one instantly.
>
> I already told you this won't help startup time because you have to
> connect blocks together in sequence. You can't build up the block
> chain backwards unless you don't care about validation at all.
I know you "told me this", but I think you are wrong. This is an example of
the problem I'm trying to get across -- I see things differently; but rather
than try and either fix my misunderstanding or see what I'm trying to achieve,
it's rejected.
I've already got it well on its way to being implemented is how I know you are
wrong. It's perfectly possible to validate backwards because you are
constructing a coherent chain based on an unvalidated start point. You then
request the parent block and either (a) you finally reach the genesis block,
you have reached a hard-coded valid point and the entire chain is therefore
instantly validated or (b) you have a new start block, floating but validated
to be part of the chain, if not absolutely validated. Further, with some
checkpoints hard coded you don't even need to reach the genesis block to get a
validated chain. The body of a block obviously can't be faked because of the
Merkle hash.
And finally... who says I care about validation? Perhaps I plan a situation
where I implicitly trust the peer I'm talking to (which is exactly what I do
plan). "There are more things in heaven and earth, Horatio, than are dreamt
of in your philosophy".
> > - Query miners for pending transactions
>
> Or just have them send an inv containing them after connect. I don't
> remember this one being "shot down".
I was told it had severe privacy implications; and you told me that it would
be better to wait for some sort of filtering system that was planned, which
I'd not heard of. I admit it wasn't exactly clear to me how what you
described helped with my suggestion. Your suggestion here is a good
alternative; but wouldn't it waste bandwidth? After all a receving node has
no idea whether I have been connected to another node for 24 hours before I
connect to it, and hence wouldn't need the list.
> > - Application version separate from client version
>
> You mean separate from protocol version, right?
Yep. I can well imagine that when alternative clients start appearing, some
will have bugs. It will be very handy to either work around those bugs or
simply deny version 1.4.17 of "Andy's Sexy Bitcoin Client" from connecting.
Even just for monitoring network state it's useful. There is already talk, I
see, of establishing how much of the network runs each released bitcoin
version.
> > - A way of requesting block bodies without headers (saving a lot of
> > traffic for a thin client upgrading)
>
> The cost/benefit ratio of this one isn't obvious at all. The resource
> requirements for running a full node are large enough that
> re-downloading 80 bytes per block is the least of your worries if
> you're upgrading.
The benefit I'm aiming at is to imagine a thin client that has done a fast
startup and only downloaded the headers. Then, it has a finite number of
addresses it's interested in and wants to grab only the relevant bodies from
the full chain. Or, fast startup is to grab all the headers, and then slowly
grab the transactions from the blocks.
The cost is
if( !bodyOnly )
sendHeader();
sendBody();
I can't say I'm that invested in it; but it was another one for the list of
"well I don't see what use that is" responses.
> > - Double SHA-256 for a packet checksum? Seriously?
>
> Feel free to submit a patch to disable checksum validation and see if
> Gavin accepts it. It needs to still be calculated at send time for
> other implementations.
I do feel free to write any patch I like. It's such a trivial patch though,
that I feel certain you are being faceitous, knowing full well that it
wouldn't be accepted. I'm trying to look five years in the future. I'm not
suggesting it be turned off now -- that's impossible and I'm not an idiot.
I'm trying to think of what the protocol should be and have a way of moving to
that.
The patch that is needed then is the one that makes the change gracefully.
> > - Sequence number as part of TxIn instead of part of the whole
> > transaction
>
> Sequence numbers are already part of the tx inputs. Or do you mean
> they should be part of the whole transaction? If the latter then this
> is indeed an idea that will be shot down, it's deliberate that seqnums
> are part of the txinputs and it needs to be that way for contracts. It
> can't be changed without forking the protocol anyway.
The sequence number (and perhaps I've misunderstood) allows me to replace a
transaction I've already submitted. I can't replace just one of the inputs, I
have to replace the whole transaction. It's therefore the transaction that
should have the sequence number. A signed transaction received with a higher
sequence number should displace a lower one.
I'm happy to accept that I have missed the use of the current sequence numbers
in contracts. (To be fair, the wiki says "Transaction version as defined by
the sender. Intended for "replacement" of transactions when information is
updated before inclusion into a block.")
Perhaps putting it in TxIn was because no one thought of having
OP_PUSH_SEQUENCENUMBER as a script operator.
> > Every single one of those has been shot down by one or more of the main
> > developers. I'm not a genius, and not arrogant enough to assume that
> > everything I say is right, but _nothing_? Really? There is no problem
> > that one of the above addresses?
>
> Some of your proposals address problems that need to be solved, but
> it's not clear that way is the right way to solve them. Others reflect
> either lack of understanding of the system or the fact that you don't
> value backwards compatibility whereas other people do.
Of the above, only one could be lack of understanding (txIn).
As to not valuing backward compatibility -- I certainly do. That shouldn't be
used as an excuse to freeze the protocol forever. There are version fields in
there, sensibly so; they should be used to fix problems. As I said a few
times, the incompatible changes don't have to activate straight away, they can
be delayed using the block number. Make it a block number four years away if
you want, but the sooner those changes go in (whatever they may be), the more
likely it is you'll get the majority of the network to change over. And once
the alternative clients start appearing, the opportunity is gone -- if it's
hard to get one client to change, imagine how hard it will be to change five.
As I said above though, I don't want these fights. I know full well that what
I want is not what you all want as far as client ideas go. I only started
this response because I thought Gavin's "we don't want new developers for new
features, we want bug fixes" was a bit of a foolish thing to say.
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/20110811/18c8c85d/attachment.sig>

2023-06-07 02:14:36

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: A discussion on backward compatibility in Bitcoin development, with one participant suggesting a single release for all changes instead of incremental updates.
📝 Original message:On 2011 August 11 Thursday, Joel Joonatan Kaartinen wrote:
> On Thu, 2011-08-11 at 06:47 +0100, Andy Parkins wrote:
> > Again you're missing my point... you are still shooting ideas down.
>
> And you're only shooting his actions down without indicating clearly
Yeah, shooting down a shooting down, which you've just shot down. Where will
it end?
> what you think ought to be done instead. What do you want him to say
> instead?
How about:
"This is a good idea, but we don't want to break backward compatibility a
little piece at a time. Instead we'd like to collect all such changes into
one single compatibility breaking release. Here's the wiki page you should
update; and here's the git branch you should push changes like this to."
> most suggestions you point at have been discussed about before
I know the application/protocol version split has been discussed before, but
please point me to the relevant discussion on: loading the block chain in
reverse; transaction only requests; checksumming removal; verack removal;
storing script parameters outside the script; and requesting blocks by
transaction hash instead of block hash.
If I've missed all of these discussions and their inevitable logically
indisputable rejection, I apologise.
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/20110811/bc780656/attachment.sig>

2023-06-07 02:14:26

- reply

📅 Original date posted:2011-08-11
🗒️ Summary of this message: A developer suggests delaying incompatible changes until they have propagated, but the community is hard-wired against breaking changes.
📝 Original message:On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:
> > However... The version number field combined with the massive
> > complexity of:
> >
> > if( blockNumber > 500000 )
> > new_process();
> > else
> > old_process();
> >
> > Would sort all of your "compatibility" objections out, and would give
> > nodes time to upgrade.
>
> The above has been discussed on the forums. The community seems to
> consider that option one of last resort, because the consequences of
> -not- upgrading immediately become "I cannot access my money." The
Did you even read what I wrote? "if( blockNumber > 5000000 )" is about as
far from immediate as you can get. I'm not an idiot; I understand we can't
lock people out of their money simply because of a software upgrade. It's
not unreasonable to expect people will have upgraded by block 500000 though
(or whatever number the community decided upon).
Again you're missing my point... you are still shooting ideas down.
> community also seems rather hard-wired against breaking changes like
> that, because it implies that we lowly dev peons are daring to mess
> with the Blessed Satoshi Design that has received extensive study, and
> 100% communal agreement.
Well the community had better unhardwire itself or its going to end up with
five developers and no more.
> If the community changes its mind, and there are strong calls to make
> a breaking change, we can certainly do that. Bitcoin is not only open
> source but very much democratic -- people vote by choosing which
> client software to use.
Voting with ones feet should be a last resort. Wouldn't it be better not to
end up with incompatible clients out there?
> Historically speaking, the protocol has had minor tweaks, if you check
> the patch history. Adding new protocol commands is pretty easy, for
> example. Removing commands tends to be high cost for low benefit
> ("protocol removes a harmless redundancy"), if you're messing with the
> initial negotiation sequence. IMO verack is not redundant, anyway.
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am willing to lower to version 5 so I shall continue
or
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am unwilling to lower to version 5 so I shall hang up
or
Client: I speak version 5
Server: hmmm, I speak version 10, but I am willing to speak version 5
or
Client: I speak version 5
Server: hmmm, I speak version 10, and I am unwilling to speak version 5
so I shall hang up
'verack' is redundant. It sends no information and merely says that the
other end is willing to continue. Willing to continue is easily determined
when the remote continues. Handling 'verack' is an annoyance, and adds
nothing.
> But the answer is "what do the users want" not "no" At the end of the
> day we're here to adequately reflect the needs of our userbase at all.
> And so far, the userbase seems highly conservative when it comes to
> incompatible changes. Correct me if I'm wrong...
Please point me at a single incompatible change that has been rejected by
the userbase.
Further: I'm not suggesting incompatible changes alone; that would be
insane. I'm suggesting upgrade paths that delay incompatible changes until
the change has propagated.
> It's negative to weight costs vs. benefits? That is what I expect any
> good engineer to do.
I don't think that's what's happening. Not once have I seen the "benefits"
side of that equation. What I have seen is plenty of "I can't see a use
case for that"; when the key word in that sentence is "I".
> In any case, our -users- are not clamoring for breaking changes of the
> type you describe above, as far as I can see. Just the opposite. So
> if you want to deploy a breaking change, the burden is on you to
> convince the bitcoin users and miners that it's a good idea.
The users aren't typically going to be familiar enough with the internals of
bitcoin to care about many of the changes I suggested. I have repeatedly
said I don't want to break anything, I want to transition in an orderly
fashion (and the majority of my suggestions were backward compatible). But
of course, I don't actually want to do anything with bitcoind itself, it's
been made repeatedly clear to me that anything I might ask for is not going
to happen -- and of course what I was pointing out, _not_ asking for, was
that you can't expect to get new developers on board if they aren't going to
be allowed to scratch their itches.
> If the bitcoin dev team is not accurately reflecting the desire of its
> users, then that should be corrected, and we want to hear feedback.
You've just had some. The response was "you're wrong".
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:14:19

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: A developer suggests improvements to the Bitcoin protocol, but they are met with resistance due to concerns about backward compatibility and disrupting monetary access.
📝 Original message:On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote:
> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins at gmail.com>
wrote:
> > Don't believe me? Here's a list of ideas I've had "no, no, no"d so
> > far; not one of which would have any financial implication at all.
> > Only some of which would break backward compatibility.
>
> Breaking backwards compatibility means breaking people's access to
> their own money.
I wasn't actually giving a full explanation of how these things could be
done, I was providing a list of "negatively received ideas"; imagine my
surprise that they have been negatively received by you.
However... The version number field combined with the massive complexity of:
if( blockNumber > 500000 )
new_process();
else
old_process();
Would sort all of your "compatibility" objections out, and would give nodes
time to upgrade.
> If you remove an "unnecessary" step that existing nodes expect, then
> the cost of disrupting monetary access seems higher than the value of
> that breaking change.
If only there were some way of sending different things to different nodes,
based on some sort of version number field.
> > - Remove verack, as it's completely unnecessary.
>
> Compatibility issues?
if( Version < VERSION_INTRODUCED )
sendVerack();
My point is that you are a clever guy; you are perfectly capable of coming
up with these answers, but you don't want to. Nor does any other bitcoin
developer. The protocol is perfect and there is no way of changing it.
> > - Query miners for pending transactions
>
> I could see value in querying a bitcoind node over JSON-RPC for
> pending transactions... and by extension, supporting that as an RPC on
> various miners' pool servers. Having a local dump of pending TX's
> would be useful.
>
> As an optional bitcoin P2P protocol command, available to anyone,
> seems to negatively impact privacy.
Eh? The transaction list is available on bitcoincharts. If my node had
been connected it would have received that list anyway when each one was
broadcast. What possible privacy loss could there be by making it possible
to request it be repeated?
Again though: the detail isn't the point. It's another half-hearted
objection.
> > - A way of requesting block bodies without headers (saving a lot of
> > traffic for a thin client upgrading)
>
> Do you mean headers without bodies? Gavin wants to work on
> headers-only, from what I've read, but others are welcome to
> contribute patches.
No; I mean being able to ask for just the block without the header. The
reason being that a thin client might request blocks on demand... it's
already got the header and doesn't need it again.
The response: "it's only 80 bytes, blah, blah". 80*150000*N is a non-
trivial amount of traffic.
> > - Double SHA-256 for a packet checksum? Seriously?
>
> Compatibility issues?
Only for the version message. But it would be trivial to do both types of
checksum on the version message, and if either is true to accept the version
message. After which the version is known and a much simpler checksum could
be used for subsequent messages. Eventually the network would be upgraded
enough that the old way can be dropped.
Besides... hasn't TCP already got checksumming? Let's just stop checking
the checksum. Or better still, stop calculating it and sending it. Double
SHA-256 on every single message on every single node to create four checksum
bytes is an enormous waste of CPU.
> > - Sequence number as part of TxIn instead of part of the whole
> > transaction
>
> Compatibility issues?
If only there were a version field in the transaction and block structures.
Again; casual rejection.
> > - Script parameters should be stored outside the script, and reference
> > by the script. All that ridiculous filtering of the scripts in
> > OP_CHECKSIG would then go away.
>
> Compatibility issues?
See above.
> > - MSG_DOUBLESPEND... nope
>
> Does consensus want this?
No, "consensus" doesn't. I was simply listing all the ideas that got
rejected out of hand. The reason "consensus" doesn't think this one is
necessary is because "we can already detect double spends by being widely
connected"; ignoring the fact that a light or intermittently connected
client would not be widely connected. But that's okay because "eventually
payment processors will appear". Yep, my idea for fixing bitcoin is stupid
because eventually someone else will mitigate it.
> > - getblocks to accept MSG_TX and do something sensible
>
> Link to elaboration of use case and need?
It was a few weeks ago; and it was an email from me about getblocks
enhancements. It was patronisingly laughed off as being something that all
you newbie "alternative client" writers go through.
The use case is an on-demand thin client that wants to find the block that
contains a particular transaction ID without downloading and indexing every
single block in the chain. Additionally, _I_ plan to separate the block
chain and wallet executables, so much so that the wallet executable doesn't
necessarily need a local blockchain node and relies on a partially trusted
remote -- it still wants to be able to do spot checks on that remote, and
confirm whatever it's told. I would like to be able to do that using only
commands that are in the official protocol; but I'm rapidly coming to accept
that nothing I ask for will ever go in because there is no "use case".
> Well, one unfortunate current aspect of bitcoin is... there seem to
> be problems aplenty right now :)
As with every project.
However, the protocol is being treated as if it is some kind of holy scroll,
and must not be touched. Bitcoin's ideas are revolutionary, its
implementation is not. If we started again today, it would be done
differently. Shouldn't we be trying to move the current protocol toward
_that_ "done differently" as much as possible while bitcoin is still
relatively small? Rhetorical again... I know the answer, it's "no".
What exactly do the developers mean when they keep talking about bitcoin as
"experimental"? It seems to me they mean "incredibly conservative, with no
changes for the rest of time".
> However demotivating it may be, keeping the current system running
> must take priority over new features.
Nothing I've suggested was to "stop the current system". I'm not even
asking for developers to prioritise my ideas. I would just like mine, or
anyone's ideas to not be instantly rejected out of hand. I mean for
goodness sake, even "splitting into multiple executables" has been stomped
on in this very thread. If something as trivial as that is "impossible"
what chance is there that I would ever get "Change the 64-bit timestamp
field to be microseconds since the epoch instead of seconds" in?
> I also heartily encourage others to do something I always want to do,
> but for lack of time: work on the design for bitcoin v2 ("theme: any
> breaking change is acceptable, it is a new block chain") There you
> may improve the protocol, get rid of the patent-cloudy ECDSA, use
> google's protocol buffers for encoding, make the proof-of-work
> algorithm memory-intensive, and other excellent, thoughtful
> breaking-change suggestions that have been made.
There is a popular idea that some other cryptocurrency will come along and
displace bitcoin. It's not going to happen. Networking effects mean that
there is no reason for people to change. I can just see the queue around
the block now for bitcoin.2; identical in function to bitcoin except it
"doesn't use ECDSA and the it uses protocol buffers on the wire, and uses
more memory". Wow; there's a set of unique selling points. I'll get signs
made.
Let's be practical: technical-only improvements _have_ to be to bitcoin.1.
Bitcoin's financial features are already complete or in progress; and it is
financial features that would make people migrate to a competitor. Nobody
is going to move to bitcoin.v2 because the source code has better comments.
> Securing the integrity of money means that a lot of implementation
> decisions have been cemented into stone, however much we may
> personally dislike them. Backwards compatibility is paramount.
I disagree about how set in stone these things are; but yeah; I've accepted
that I'm on a loser. My list was to demonstrate how negative the community
is; and you have confirmed that for me admirably. Bear that in mind the
next time you're discussing the lack of manpower for bug fixes.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:14:13

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: A potential developer expresses frustration with the aggressive rejection of new ideas and lack of support for new developers in the Bitcoin community.
📝 Original message:On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote:
> > 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.
>
> This is true -- though there is value to having a list of "things we
> think people should focus on" for the motivated, and for new people
> interested in tackling a project, but not sure what project to tackle.
My objection is not that such a list exists, it is that potential new
developers are, essentially, shouted down unless they are working on that
list. I cannot imagine that many new developers arrive under those
circumstances.
> A centrally managed development branch on bitcoin/bitcoin.git is not
> the way to do it, however. See the description of linux-next, in my
> previous email, for a more distributed method which can easily be
> layered on top of the existing bitcoin dev structure by any motivated
> volunteer(s).
I don't think I said anything about it being centrally managed. git lets us
store these branches anywhere of course. The fact is that such a branch
exists somewhere.
> Think distributed. :) The community does not need Linus's help
> (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next
I didn't say that it required anybody's help; but it does require a bit of
willingess on the part of the master-branch-owning developers to import from
that branch.
> became so widely used and useful that Linus requires almost all
> changes to be first staged in linux-next.
They key thing with linux-next is that work done on it _does_ make it into
the kernel. Tell me -- how many feature branches for bitcoin are just
sitting as a pull request on github, and are now months old and abandoned
out of disgust by their original authors? Here's another question: why is
it that so many projects have "specially compiled" versions of bitcoin?
Rhetorical question... it's because the official client doesn't do what they
need, and won't accept their patches to add it (even optionally).
I've only been watching this list for a few weeks (since the forum turned
into an echo chamber); but I'm completely depressed by the agressive
rejections of every new idea anyone raises.
Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not
one of which would have any financial implication at all. Only some of
which would break backward compatibility.
- Extra bits in the service field of the version message to allow nodes
to indicate if they are mining; if they are willing to be seed nodes;
if they relay transactions; if they want relayed transactions.
- getblocks in reverse chronological order so clients can start up quicker
while downloading the blocks in the backround. Ironically I was told
"patches welcome" by someone who didn't reject this one instantly.
- Remove verack, as it's completely unnecessary.
- Query miners for pending transactions
- Application version separate from client version
- A way of requesting block bodies without headers (saving a lot of traffic
for a thin client upgrading)
- Double SHA-256 for a packet checksum? Seriously?
- Sequence number as part of TxIn instead of part of the whole transaction
- Script parameters should be stored outside the script, and reference by
the script. All that ridiculous filtering of the scripts in OP_CHECKSIG
would then go away.
- MSG_DOUBLESPEND... nope
- getblocks to accept MSG_TX and do something sensible
Every single one of those has been shot down by one or more of the main
developers. I'm not a genius, and not arrogant enough to assume that
everything I say is right, but _nothing_? Really? There is no problem that
one of the above addresses?
Given that, what do I do? Hang around and get battered some more, or go
away to my own little corner and work on my own implementation?
You can imagine then that when I read moans about there not being enough new
developers fixing bugs, that I am unsurprised and unsympathetic. I like
bitcoin enough to hover on this list; and offer a view of your world from a
potential developer who was chased away.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:14:06

- reply

📅 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

2023-06-07 02:12:59

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: The number of connections in a network needs serious thought, too many and you fill everyone's connection slots, too few and you don't have a network.
📝 Original message:On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
>
> Number of connections is something that needs serious thought. Too many
> and you fill everyone's connection slots and no one can make
> connections. Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.
I'm arguing that "number of connection slots" isn't the best metric; so that
wouldn't matter. Just keep accepting incoming connections (with some sanity
limit of course) until you've allocated your bandwidth, not your number of
connections.
If I connect to a thousand nodes and never send anything, I'm not using up
very much of their resources. If _they_ want to use up resources by relaying,
then that is their choice, but again they can do that based on bandwidth
calculations rather than connection counts. If I am sending, then that adds
to their bandwidth and gets included in whatever limit they've chosen.
For example: the client could simply maintain an average bandwidth over all
connections. If that average is less than threshold0, then make new outgoing
connections. If that average exceeds threshold1, then stop accepting incoming
connections. If it exceeds threshold2, start dropping established incoming
connections. If it exceeds theshold3, start dropping established outgoing
connections.
The actual rules don't matter so much; I'm just saying bandwidth is a better
metric than connection count. If you limit by connection count, then you'll
just end up filled with non-relaying listeners, since they (in the future)
will be the most commonplace. You'll have no incoming relays, and therefore
nothing to forward, so your bandwidth will be zero, but your connection count
at maximum -- you've locked yourself out.
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/20110805/c74ccaae/attachment.sig>

2023-06-07 02:12:53

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: The number of connections a node should use in Bitcoin is arbitrary; bandwidth is the relevant metric, and connections should be added until the bandwidth limit is reached.
📝 Original message:On 2011 August 05 Friday, Mike Hearn wrote:
> How many connections "should" a node use? We faced this decision in
> BitCoinJ recently and I asked the patch writer to reduce the number.
> It seems pretty arbitrary to me - if you aren't going to relay, a
> single connection should be good enough. Yes, it makes sybil easier,
> but if you pick the one node randomly enough it might be ok?
I don't really see that "number of connections" is the relevant metric. For a
well designed bit of software the number of connections shouldn't matter.
There's a bit of overhead in the operating system per connection, but I'd be
surprised if that ever became a limiting factor in a stateless system like
bitcoin. In fact, bitcoin would work perfectly well as a UDP system (I'm not
advocating that of course), and then there would be no such thing as a
connection.
Bandwidth is the measure that's relevant.
Therefore if bandwidth is the measure, just pick a bandwidth you like and
add/accept connections until you hit that bandwidth limit (probably averaged).
This has the advantage that it can be measured automatically, or sensibly set
by a user.
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/20110805/4090edad/attachment.sig>

2023-06-07 02:12:11

- reply

📅 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

2023-06-07 02:12:05

- reply

📅 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

2023-06-07 02:11:58

- reply

📅 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>

2023-06-07 02:11:50

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: A mechanism to deanonymize Bitcoin transactions involves connecting to every node in the cloud and identifying the first IP consistently relaying transactions for a given identity.
📝 Original message:On 2011 August 05 Friday, Gavin Andresen wrote:
> "As reported, I've got a BitCoin deanonymization mechanism. It's not
> complicated.
>
> Connect to every node in the cloud, discoverable via sweeping/IRC/get_peers
> messages. The first IP to consistently relay transactions for a given
> identity, is the given identity.
Transaction forwarding could be randomised slightly, by randomising the
outgoing relay order; and adding a random delay between each forward. Even
the massively connected monitor can't represent _all_ the connections on every
real node, so it would have no way of knowing whether it got any transaction
from the originator or because it got a fast path through the first N nodes to
receive it.
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/20110805/dd11a165/attachment.sig>

2023-06-07 02:05:09

- reply

📅 Original date posted:2011-07-13
🗒️ Summary of this message: A debate over the arbitrary nature of the constant value of 21 million in Bitcoin's code, which represents the maximum number of coins that can be mined.
📝 Original message:On Wednesday 13 July 2011 19:37:57 Luke-Jr wrote:
> On Wednesday, July 13, 2011 9:04:09 AM Andy Parkins wrote:
> > TCoinsElement MAX_MONEY;
>
> This isn't an arbitrary constant, it's the result of a calculation...
Don't tell me:
bitcoin/src/main.h:41
static const int64 MAX_MONEY = 21000000 * COIN
21,000,000 seems pretty arbitrary to me.
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:05:03

- reply

📅 Original date posted:2011-07-13
🗒️ Summary of this message: Dr. Andy Parkins is working on a similar project to BitCoinJ's NetworkParameters abstraction, which groups together constants used in the official client.
📝 Original message:On 2011 July 13 Wednesday, Mike Hearn wrote:
> For what it's worth, BitCoinJ has a NetworkParameters abstraction that
> does what you suggest (groups all the constants together):
"all" is a strong word :-)
I'm doing a similar thing, and so far I have (and it's definitely incomplete)
the following for these magic-constants that are often literals in the offical
client:
TBlock *GenesisBlock;
TBitcoinHash ProofOfWorkLimit;
uint16_t DefaultTCPPort;
uint32_t Magic;
uint8_t BitcoinAddressPrefix;
unsigned int COINBASE_MATURITY;
unsigned int COINBASE_MINIMUM_SCRIPT_SIZE;
unsigned int COINBASE_MAXIMUM_SCRIPT_SIZE;
unsigned int MAX_BLOCK_SIZE;
unsigned int MAX_BLOCK_SIZE_GEN;
unsigned int MAX_BLOCK_SIGOPS;
unsigned int MINIMUM_TRANSACTION_SIZE;
TCoinsElement MIN_MONEY;
TCoinsElement MAX_MONEY;
TCoinsElement MIN_TX_FEE;
TCoinsElement INITIAL_MINING_REWARD;
unsigned int INFLATION_PERIOD;
unsigned int BLOCK_TIMESTAMP_WINDOW;
unsigned int DIFFICULTY_TIMESPAN;
unsigned int NEW_BLOCK_PERIOD;
unsigned int INV_MAX;
unsigned int GETDATA_MAX;
unsigned int GETBLOCKS_RESPONSES_MAX;
unsigned int GETHEADERS_RESPONSES_MAX;
unsigned int ADDR_MAX;
unsigned int ADDR_MIN_TIME;
unsigned int ADDR_MAX_TIME_OFFSET;
unsigned int ADDR_DEFAULT_TIME_PENALTY;
unsigned int ASSUME_OFFLINE_AFTER;
unsigned int OFFLINE_UPDATE_INTERVAL;
unsigned int ONLINE_UPDATE_INTERVAL;
map<unsigned int, TBitcoinHash> Checkpoints;
static const TBitcoinHash NULL_REFERENCE_HASH;
static const unsigned int NULL_REFERENCE_INDEX;
Any suggestions for others gratefully received.
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/20110713/ae0f506a/attachment.sig>

2023-06-07 02:03:28

- reply

📅 Original date posted:2011-07-07
🗒️ Summary of this message: A lightweight client needs to calculate the balance of an arbitrary address without requiring the whole blockchain. A filter-by-address could help.
📝 Original message:On Thursday 07 July 2011 17:44:48 Mike Hearn wrote:
> > What I want to be able to do though is calculate a balance for an
> > aribtrary address. Not every address; just the particular ones that
> > the client is interested in. It's complete overkill to require the
> > whole block chain just to calculate the balance of a few addresses.
>
> But what is that for? You said it's for a lightweight client to do
> that when it receives a transaction, to verify that all the
> dependencies are in blocks recursively. But why?
There is no way for a client to know in advance whether any broadcast
transaction contains a send to an address in its wallet. So every incoming
transaction has to be examined.
Then, there is no way to know if while you were offline any of the
transactions in the blocks you missed contained transactions for an address
in your wallet.
Also, a feature I am interested in supporting is a split wallet -- where the
private key is held elsewhere. I'd still want to be able to report the
current balance in a particular address though. That address can be added
at any time.
Also, I would like to make some blockexplorer-like facilities available to
lightweight clients.
> > Not entirely. If I ask for "the block that contains transaction with
> > hash 12345678abcd..." then when I get that full block, I can verify
> > the merkle tree myself.
>
> Well, it's more efficient to just verify the merkle branch. But yes.
We're only talking about one verifying one (or minimal numbers of) blocks;
"efficient" isn't really going to matter much in that context. Also, if
we're talking about a situation where we don't necessarily trust the remote,
we've got to verify the whole block, not just the one transaction we're
interested in, since we told the remote which one we were interested in when
we requested it.
> > I'm not entirely sure I see how a filter helps. If I've been offline
> > for ten minutes then I need all the transactions pending in the last
> > ten minutes. No amount of filtering makes that list any smaller.
>
> Why do you need all of them? You just care about the ones sending
> coins to you, surely?
Is the filter going to be filter-by-address then? I misunderstood in that
case, I thought you were talking about filter-by-hash, which obviously tells
you nothing about the contents of the transaction.
> > That would be fine. My reason for suggesting using getblocks was that
> > it didn't introduce a new command.
>
> IMHO it's fine to introduce new commands. They'll just be ignored by
> old clients in any event.
That's good to know. I'm trying to be circumspect in what my client does; I
want to be 100% compatible, which means if I need a new feature, it's got to
be in the official client first.
I accept that this is all big talk, and there are plenty of people who start
new clients and then give up; which might still happen to me.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com

2023-06-07 02:03:21

- reply

📅 Original date posted:2011-07-07
🗒️ Summary of this message: A lightweight client only interested in the history of its own wallet addresses cannot request transactions and ensure they are all valid and in blocks.
📝 Original message:On 2011 July 07 Thursday, Mike Hearn wrote:
> On Thu, Jul 7, 2011 at 11:49 AM, Andy Parkins <andyparkins at gmail.com> wrote:
> > Imagine this situation though. I am a light weight client. I store the
> > block headers only. I am only interested in the history of my own
> > wallet addresses. I receive a block broadcast with a transaction that
> > sends coins to one of my addresses. That transaction references other
> > transactions (of course), but I haven't stored any transactions. So; I
> > want to request those transactions and ensure they are all valid and in
> > blocks. I can't.
>
> Everyone writing an alternative client goes through this thought
> process :-) There's no point in doing it, you cannot prove your
> transaction is not a double spend. That requires knowledge (ie, an
> index) of all transactions.
Ah; you mistake me. I'm not interested in double spend prevention, in this
case I'd be willing to trust the full node to return whatever block it thinks
contains that transaction, and that it has already done double spend
prevention.
What I want to be able to do though is calculate a balance for an aribtrary
address. Not every address; just the particular ones that the client is
interested in. It's complete overkill to require the whole block chain just
to calculate the balance of a few addresses.
> You have to treat appearing deep in the chain as ipso-facto proof of
> validity. Lightweight/SPV clients simply must have that trust, it
> cannot be done any other way. See this article:
Not entirely. If I ask for "the block that contains transaction with hash
12345678abcd..." then when I get that full block, I can verify the merkle tree
myself. I do have to trust that the peer hasn't been adding double spends in,
but not that the transaction is actually in the chain.
> > It should be possible to request the current pending transaction list.
>
> I think it'd be better to implement the filtering suggestions that
> have been made. It doesn't scale to download the entire memory pool -
I'm sorry, I've only started watching this list in the last few days. I'm not
familiar with the filter suggestions.
I'm not entirely sure I see how a filter helps. If I've been offline for ten
minutes then I need all the transactions pending in the last ten minutes. No
amount of filtering makes that list any smaller.
> a better approach is to give the remote node a filter to match against
> transactions then have it only relay those. After setting a filter,
> transactions pending and matching would be sent in one big inv and you
> can then keep the connection open to learn about new transactions
> without needing to "drink from the firehose". Filters can be
> probabilistic and set on many different nodes to reduce the privacy
> implications.
That would be fine. My reason for suggesting using getblocks was that it
didn't introduce a new command.
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/20110707/0c3f8d5e/attachment.sig>

2023-06-07 02:03:15

- reply

📅 Original date posted:2011-07-07
🗒️ Summary of this message: A proposal for two changes to the Bitcoin protocol, including the ability for lightweight clients to request transactions and a virtual block for pending transactions.
📝 Original message:Hello,
This is a suggestion with a mind to the future. In particular, I'm slowly
working on an alternative client and library (I know, everyone says that).
I've got a feature that I'd like to have that would need a change in the
protocol. It's a change that I think would improve the official client as
well, so I'm bringing it up here.
It's actually two changes; and both could be acheived by adding new commands
to the protocol. I think that would be overkill though; as they fit quite
nicely into an extended getblocks command.
(1) The getblocks message is a list of inventory items (type MSG_BLOCK) being
requested.
Imagine this situation though. I am a light weight client. I store the block
headers only. I am only interested in the history of my own wallet addresses.
I receive a block broadcast with a transaction that sends coins to one of my
addresses. That transaction references other transactions (of course), but I
haven't stored any transactions. So; I want to request those transactions and
ensure they are all valid and in blocks. I can't.
I can request the transactions themselves; but I have no way of finding out
what block they were in without downloading the entire full block chain
myself. The thing is, a peer with the full block chain is able to do this
instantly.
Here then is my suggestion: getblocks should accept inventory items of type
MSG_TX as well as MSG_BLOCK. When it finds a MSG_TX request, it shouldn't
send the transaction (after all that is what the getdata message is for);
instead it should return the block that contains that transaction. It's an
alternative way of requesting a block -- by transaction in that block.
It should be obvious then that it would be easy for a lightweight client to
request the transaction chain transactions its interested in to create a list
of relevant hashes for the history it's after; and then put those hashes in a
getblocks request and have to look only at a few full blocks instead of the
full block chain.
(2) If you are offline when new transactions are broadcast, there is no way to
know they are pending.
Transactions that have been broadcast but not yet accepted into a block are
never resent (nor should they be). But if I am on a mobile client say, or a
light-weight, intermittently used client; I have no way of checking if a
transaction sending coins to one of my addresses is pending.
It should be possible to request the current pending transaction list.
My sugestion then is that a special virtual block request be possible. The
all zero block hash can never exist (it's used as the parent for the genesis
block, so it had better not). If I send a getblocks that contains an all-zero
hash, then the virtual block should be returned in a block message. That
virtual block will list all the current pending transactions. Obviously there
would be a problem that it's actual hash would not be zero; so it would have
to be marked as the virtual block in some other way (perhaps a zero timestamp
plus a zero parent hash, or similar).
The combination of the above two protocol changes makes it possible for any
client to have a large chunk of the facilities available in blockexplorer.com
and the very useful http://bitcoincharts.com/bitcoin/ information.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com