It can't in that case, thats why it has an optional scriptpubkey argument.

An immutable ID is not _generally_ possible— since some forms of mutability are very much intentional (e.g. anyonecanpay), and also isn't generally needed. Presenting an "immutabile ID" which sometimes isn't would seem very dangerous to me.  You can track your own transactions by which outputs they pay, or by which inputs they spend (so long as you aren't doublespending yourself), or both.

WRT, -1 confirmations, it doesn't strictly mean "never will" since there could be a reorg that takes a transaction from -1 to confirmed, but it does mean that it cannot be confirmed in the current chain without a reorganization.

Doug, you've asked several questions now which are 'down in the weeds' and don't describe what you're trying to accomplish. You can usually get more useful answers if you also tell people what you're trying to do.

It sounds to me that it is.
I'm not interested in participating in a secret process. I'll comment on public proposals, as I have time available and if they're remotely interesting.
They haven't, as far as I know.

In the case of exploitable vulnerabilities keeping people safe can be at odds with transparency. In Bitcoin what we've tried to do is narrow any vulnerability down the a non-consensus behavior where implementations would reasonably expect to differ, or the smallest 'bad' behavior, the corner case the attack requires that no one had previously considered, and narrowly fix that... The idea is that the broad behavior of the system is part of the contract between all of the users that no one has the right or ability to just unilaterally change—  but some "it crashes in this case" wasn't part of the contract, and if we carefully remove only the crash via a not-very-transparent change which is compatible with people continuing to run the old code, then we've done the minimum evil there.

Changes to the long term, broad scale behavior, stuff which isn't an immediately exploitable vulnerability— that stuff absolutely must be discussed in the open. It's hard enough getting quality review for complex design decisions in cryptographic protocols which are openly discussed, moving in the shadows is suicide.  It's true that in theory people can suss out the behavior of these things from the code-drop patches and decide to run them or not— call the alarm bells that the developers have hidden some kind of concerning change, but the cost of reliably finding that stuff is high. If a situation is created where a publicly used cryptocurrency has a cabal that is making large design changes in secret, then thats not a really decenteralized system. Technical compeition isn't an excuse for undermining the decentralization that supposedly makes this stuff valuable in the first place, it's just another example of the shittyness of the altcoin space— they're often developed by greedy people who put their profit first.  This has been a complain I've raised a couple times with the Bytecoin-forks, their openness-relative-to-bytecoin sales pitch doesn't really seem to agree with their behavior.

Of course, that kind of hyper competitive approach also makes it hard to report actual vulnerabilities— the more competition there is, the more concern that if you report it to them they'll just use it to attack each other.

In this case perhaps the brain damaged block sizes are more immediately exploitable that I suspected, I was expecting it to be discussed in the open because I believed it was only a long term disaster, not also a short term one too. If so, I'm sorry for whining that the development of the fixes isn't in the open; though I'd still encourage everyone to separate narrow fixes from more substantive changes.

Thats really disappointing, I thought that sort of lack of transparency in Bytecoin was what justified your fork in the first place?  Not to mention the practical ramifications— the brokeness of the current behavior was instantly obvious to me when I saw it, but too bad it was in an already deployed system.  You do no one any favors developing in secret.

Where is this being discussed? (sorry for the OT, but I suppose the changes are relevant for all the derivatives)

Quite the opposite. Merged mining normally has no reliance at all. It's just the same work used in two places via a commitment. The things that FCN is merged with can stop existing and FCN would continue along fine (which is also demonstrated by FCN not caring at all).

The fact the merged mining is a non-trivial protocol change should be interesting— right now it generally seems that the bytecoin ecosystem as a whole doesn't have a lot of hard core technical attention on it, which is concerning, considering some of the issues in the system (e.g. the completely unhinged blocksize controls)... the fact that FCN has people working on it who are willing and able to do lowlevel protocol work is a positive sign.

Incorrect.  People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too.  In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security.  This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Funny, I've seen similar disinformation published before— that person was unwilling (unable) to substantiate it— can you do better?   The comments I made on Zerocoin were, I think, reasonably positive— but at the same time the system as it was wasn't suitable for deployment, and was later replaced by a complete reboot with much better performance (also evidence by the fact that no altcoin has deployed it, though they made a nice implementation of the cryptosystem available). I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

This has really gone off-topic, but I thought leaving the FUD sitting around would be harmful.

We're aware of that and specifically designed to address that— at least to the extent that we easily can, there is a lot of room for improvement here. You cannot completely disconnect tor peers using the attack they described because we use tor in two distinct ways:  One way is that we use tor via exit nodes, which that attack addresses— the other is that we use tor via hidden services. If you set onlynet=tor your tor-enabled node uses only this second mechanism, otherwise it uses both. Inbound connections from hidden services, if you have enabled them, are exempted from banning. Some nodes are dual stack— they receive connections via both IPv4 and tor hidden services, and thus act as bridges between the tor and non-tor hosts even if no tor exits are working.

It may well be the case that you could actually break Bitcoin on tor by also DOS attacking the HS-accepting hosts, since there aren't enough of them, and the defense above works in part because some of the existing DOS protections are disabled for HS peers so HS accepting nodes are more DOS vulnerable— though it might also be the case that you'd just break the tor network first, and there isn't much we can do about that.

Last year I proposed a novel approach using asymmetric storage costs to discourage hosts from connecting out to many peers concurrently, though since there have been no attacks (at least none that have risen to a sufficient level of irritation) there hasn't been a lot of interest in developing the idea further. Basically the idea has the outbound connecting host do a moderate amount of POW to precompute a table per peer they are connecting to that allows them to rapidly answer queries that the remote peer can efficiently compute (without storage), the remote peer continually challenges them, so that they must either constantly be doing a ton of POW work, or retain a fair amount of storage per peer.  I'd envisioned this to be an optional thing peers could signal at their connection time ("I'm willing to use up to 1GB storage to get priority access"). All of these "make connections costly" approaches open new attack avenues, however— e.g. what happens when you start a lot of useless nodes for the purpose of just making peers waste effort to connect? The best answer I had is that nodes would only perform the costly work to secure their connections with a small number of their 'favorite' peers (e.g. randomly selected peers which have proven themselves to be helpful in the past), but this only requires the attacker to make their misbehaving nodes good for a while before they start misbehaving. Using sustained local storage as the costly thing instead of one time POW has the useful property that the storage can be freed if a peer stops being useful, but sadly my approach still requires the initial setup be somewhat computationally expensive or otherwise an attacker can skip the storage and just redo the setup for every challenge.

WRT topology, we've worked to keep the wiring random in order to make the topology likely to be an expander graph. Concern about not screwing up the topology is why we don't yet have peer rotation— the first and most obvious way to do it that I came up with broke the topology in simulation (resulted in clustering that had a smallish min-cut). I'm reasonably confident that I know ways that won't, but it's always scary to change something which is hard to analyze.

Blockchains are generally the wrong tools for evoting— they don't solve any of the hard problems presented by that space.  They don't provide for censorship resistance (blockchains are not jamming free networks), they are generally privacy disasters (so they certantly don't help ballot confidentiality). They are not a sibyl free issuance mechanism, so they don't prevent parties from getting an unfair share of the votes.

I think electronic voting systems are exciting and interesting, but if you're using technology from Bitcoin to implement these systems you are likely using the wrong tools and will build something which lets people down.

Thats only a restriction in popular software, it's not a fundamental technical limitation.

I haven't deleted anything here. Nor did I see any post of yours saying anything like I said, instead you appeared to be loudly claming that something was wrong with eligius, you went as far to imply that something was being hidden ("Makes me wonder why he won't explain it. As should anyone who uses this pool...")

You mean the protocol every pool uses? There is basically no GBT hashrate on eligius, as is my understanding— not that there is actually any latency difference.

I'm afraid you don't understand how block timestamps work. It's possible to find a block 100ms after the prior block and yet have a timestamp a minute later (or a minute before, for that matter), times are not synchronous between miners.

And yet you can look at the actual observed blocks and Eligius is underrepresented in empty blocks relative to hashrate.

What the fuck are you talking about here?  That kind of allegations demands some links.

I linked the actual blocks, so you can see exactly where empty blocks have been produced.

Of course it can. Shit, even getwork can do that.

This is the reasonable, well known, and expected behavior and not something to be concerned about.

Standard behavior for pool software is when a new block is accepted to immediately generate new work before the new transaction list is computed and then long poll again later to update. It can take bitcoind several hundred milliseconds to generate an actual block with content, especially if the mempool is large, and otherwise in that time you'd be twiddling your thumbs doing nothing or uselessly working on an old block. As a result, all miners will produce an empty block here and there, even when there is a backlog (E.g. for a 1 second dwell time it would be 0.16% of blocks).

In the last 1000 block there were 9 empty blocks, that rate suggests an aggregate dwell time of about 5 seconds. According to bc.i they were created by Discus Fish, Slush, Discus Fish, Discus Fish, Discus Fish, Eligius, KnC, Eligius, and Discus Fish.  Perhaps one pool's over-representation there suggests their long-polling behavior could use some tuning, but it isn't Eligius…

The obvious optimizations like precomputing the next block don't work, because someone else will usually have produced this one, and your 'next' will likely conflict with it... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

Fortunately the timing of blocks are independent, e.g. that someone found a block 10 seconds after the last with nothing in it doesn't actually delay the finding of the next block with something in it.

How long are you talking about? for me it takes about 15 seconds cold-cache.  Some systems with broken IDE controllers or crazy AV can take many minutes, but thats not Bitcoin's fault. There may be other system specific cases which could be improved.

(If you're just talking about the 15 seconds— it's as folks said here... it does some validation at startup to make sure the data isn't corrupted, otherwise you could end up on a fork during runtime if the data was corrupted.  Litecoin is additionally slow because its POW is very slow to verify.)

Then please don't post in this subforum if you're not interested in Bitcoin. My tolerance for seeming market manipulation is pretty low today, and spreading FUD about issues that don't exist and then professing ignorance is not my idea of a useful contribution to the discussion.

Someone was asking for a definition of a term, thats all.
There are no problems occurring right now in the Bitcoin network.

[Edit: I'm locking this thread because the question has been answered and its gathering offtopic posts. If the original author has any more questions let me know and I'll unlock!]

Well, technically the network could prohibit it. E.g. Bytecoin (and its forks) prohibit a single public key from ever being spent from more than once. Zerocash will also require such a restriction.

Such a change is merely a soft-forking change, it only restricts the set of valid behaviors.

Right, it requires an an unprunable data structure that will grow forever.  However, you could make it lossy with most of the same privacy effect, e.g. you can't use an address used anywhere in the last 2016 blocks. This isn't an option in bytecoin, since it needs the non-reuse invariant to prevent double-spends.

hah well if this was your motivation then I guess you couldn't deploy that as a soft fork.

But you're wrong there wrt pools, it would be very easy for pools to switch to paying BIP32 chains or ECDH addresses— and they should, for privacy reasons.  Eligius' prior operator (Luke) wanted to do this, but the new management is less interested in doing things which are of long-term benefit.

For a little while Eligius was generally deprioritizing recent-address-reusing payments in their block selection as a way to discourage reuse generally and to also give more fair access to the blockchain. I'm not sure if they're still doing that.

Or that.

Welp, P2Pool exists, and could use some more love and attention.

The cryptosystem useful for a lot more than cryptocurrencies too.

I'm working on a very fun application of it right now... Will post when I have usable tools.

Thats above my paygrade other than to observe that it seems all sad and weird to me. (It's hard for me to tell what strange game of chess people are playing here, perhaps extra hard because I don't care about any of it— as mentioned I think introducing alt-currencies is a dead end route).  I mean, I could make guesses,... but it would just be guesses, my spider sense which usually protects me from weird situations certantly goes off around that stuff. Then again, I may just be miscalibrated relative to the baseline level of scum and villainy expected in the altcoin space.

Hm. My disapproval of address reuse in Bitcoin land caused me to pull the tip address from my sig— I only have a bitcoin address on my profile at all for mod payments, and I rotate that manually every time it gets paid.  ... but since all BCN/MRO/etc. addresses are ECDH negotiated, my issue there is resolved hurray!

Sure, but when we're talking about change happening over a single month?  Basically I see the idea that fixing the initial burst improves equality between the early miners, the economic effects take place on a larger time scale.

Basically I think you want the distribution itself to be locally fair while larger economic forces make things globally fair. Trade can't equalize an advantage that happens on the timescale of days or weeks very much. No programmed mining distribution system can achieve fairness over the span of years. Hopefully the two combine well enough to remove enough unfairness that we can look the other way long enough to enjoy the non-zero-sum benefit of a useful system.

I'm not trying to be sanctimonious... but rather I have a _lot_ of respect for the really clever cryptosystem used in Bytecoin. It's one of the most interesting cryptographic techniques _actually deployed_ that I've since basically bitcoin itself (there are a lot of other neat ideas, few have made it to actual use).  If this were tech that worked in Bitcoin it would have won pretty much the entirety of the coinjoin bounty hands down by my opinion.   So I don't mean to dismiss the work that has been done in the forks, but it is really not on the same level as the actual invention here in my opinion (esp since bytecoin is not a fork of Bitcoin).  Maybe in a couple years my opinion will be different.   My view is also colored by my own position as a developer who took up the maintenance of Bitcoin after its author left, e.g. I'm inclined to discount the value of contributions similar to my own.

Funny, I think lockup is exactly the opposite of what you want.  Part of what makes me generally think the situation is complex is that coins that change hands spread the appreciation around.

I'm not sure that lockup/vesting can ever really be made to really work. You can always sell your interest even if the system won't let you actually transfer it. I can sell you the private key(s), under the protection of traditional contract law and the courts that to convince you that I didn't keep a copy.  Failing that, I can also put we can some Bitcoin in an escrow to secure the deal. etc... all undetectable to the outside world.

In the case of bytecoin it just seems weird. Some day we'll discover that the code was really being written by a single brilliant grad student under contract and one day he suffered a freak brain aneurism and died. Left with no one to continue the development and without the technical chops to even evaluate new developers and concerns about the ramifications of releasing a cryptographically anonymous cryptocurrency the people funding him open sourced the works so far and hoped for the best.

I mean really, am I missing something subtle here? it's pretty hard to pull anything over on anyone. I'm not sure what we're supposed to be tricked into thinking here. It doesn't strike me as fraudulent as much as it does just weird and poorly done.  Likewise, the software is very raw, some elements of the design seem pretty poorly considered, maybe not absolutely bad but relative to the quality of the rest.  Maybe I'm a little spoiled by Bitcoin.

Well, for example, say you have a 100% "premine" coin, but most of it gets sold for a grand total of a few bitcoins.. and then sold again and again, gradually gaining value.  Sure the person upfront at an "unfair" advantage but who cares if it was just to the tune of a couple of bitcoins? — and if they put in the work to really create something original and innovative it's well earned.

Something doesn't gain real sticky value except with trade, you can't premine 100% and then expect it to be magically valuable.  So asking if something is fair or not is more complicated than asking just about how much was premined or how fast the early release was. For all we know huge chunks of that large early mining may show up as donations and bounties driving innovation in the ecosystem and between that and the speculative trading of zillions of worthless coins ultimately resulting in a more equitable distribution than even the best tuned mining lottery would give. (Sadly, the forking diminishes the marginal return of this kind of activity, since ecosystem developments will also benefit the forks, making perhaps more rational to sit back and hope the forks fund that work instead).

It isn't immediately obvious to me that some of the BCN forks are inherently more fair, they may well be, but a lot of that depends on how the overall economy plays out.  Right now, however, the differential profit to me mining bcn today vs four weeks ago is far far smaller than for say monero.  One complicating bit is that the privacy of the system doesn't even let reliably you know if coins being moved are recently created coins churning or if its old coins moving.  

Basically the mining lottery is only one element to fair distribution and its inherently limited because it is biased towards experienced altcoin early miners, computation thieves, etc. in an active economy trade tends to spread out the profits from asset appreciation, and other things like donations and bounties stemming from concentrations of wealth can further the process.  Right now the forks argument is that the mining is more fair, but even more fair is pretty substantially unfair. How it all plays out is anyones guess, I think.

Feel free to seek my input— I can't resist running my mouth even if I think the whole enterprise is ill-advised— you might be able to extract something useful.

I did call it sketchy for a reason.   But at the same time I think it's reasonable and proper that the creators of the system actually do profit from it some (at least if anyone is!) one problem with cryptocurrency launches seems to be that as soon as you launch it people with botnets and other stolen resources immediately begin mining the hell out of it— and if there is an explicit 'premine' people fork and yank it out.  I do not begrudge the creators of a system feeling they're owed _some_ payoff, the question is how to get it in a way that is actually _viable_ even before you ask for fairness.

One of the criteria that I think is a requirement for an acceptable POW function is that it be largely "optimization free"— that is that the public implementation(s) are as close to the best implementations possible. Without being confident this criteria is met an attacker can gain an advantage. From that perspective its important that the released one be good.  OTOH, you're simply not entitled to demand people give away the software they wrote for themselves especially when they're already giving you so much.  Keeping some better mining code for yourself for a little while is crappy but it might be one of the more ethical viable ways to ensure compensation.  I think, for example, that it's more ethical than encouraging unsophisticated investors to "buy in" to something that exists only as a white paper and maybe a couple tech demos— a technique used by some altcoin proposals as of late.

Being able to fund infrastructure development in this space is still an open question. I think the general model of using altcoin launches to do this is not sustainable (for one, more currencies just dillutes network effect, hurting everyone— and too much of the value goes out to lucky speculators instead of the people creating the technology... plus the supply of hopeful suckers will eventually dry up). So I'm willing to have an open mind about different approaches people used, even though I'm personally a bit uncomfortable with anything that could be seen as compromising the integrity of the software. My tolerance for approaches is weighed by how interesting the tech is. I give bytecoin more slack than I'd give most altcoins because it has actually done some very innovative things, and it's not just a white paper but a usable system released as MIT licensed code, not hype.  Relatively speaking no matter how unfair BCN's initial distribution might turn out to be once the economy takes effect, I think it's inherently more fair than the many coins that never deliver anything interesting while sucking a lot of coins out of people on the basis of a bunch of promises. Bytecoin added value to the world, maybe some of the forks will add value by improving on the flaws in bytecoin's relesase— I thank that remains to be seen. If everyone benefits then I think splitting too many hairs about some people benefiting a bit more than some others may be short sighted, but it does depend on how the economy plays out.

Well that wasn't directed at you. Ignore my whining if you like.  I'm just sad to see how short sighted people are sometimes, it isn't everyone. I'll probably show in the Monero thread once I've successfully mined a block there, hard to use it until I have some to play with.

Hm? No I'm not. I've mined exactly one bytecoin block, last weekend— as part of fooling around with it, and I've used that to make some transactions and try it out. I'm also not especially equipped for cpu mining any more, and as you may note I basically don't do anything with altcoins (except sometimes point out their technical mistakes).  I wasn't aware of bytecoin until Adam Back mentioned it (well I _heard_ about it but thought people were talking about the crappy bitcoin clone).  If I'd been involved earlier perhaps there would be fewer really awful design flaws (including the way it appears to have been launched, which I agree is screwed up). Where my opinion differs is that I think its foolish in the abstract to create separate currencies for things which are just more transaction features (which doesn't mean I may not use them, but I do not consider them virtuous). I also think some of the forks (and perhaps all of them so far) have been launched in ways which are only minimally better and also created a huge advantage for their early participants.  While I think what BCN has done is a bit crazy, relative to the forks I do think it at least has the moral high-ground of having at least been the original authors— to the extent that anyone ought to get a windfall it ought to be them.  The lack of good initial calibration is even less excusable for the forks since they knew going in what the demand would be.

(were I ever to launch some altcoin— among many other things— I'd figure out a reasonable target for what the difficulty will be once it has basic adoption, and when the difficulty is below that level I'd have it scale the subsidy that each block takes by the difficulty so that the very earliest miners wouldn't get a windfall— effectively the income per hash would be ~constant until the hashrate got above some threshold. I'd also never create something with such a costly to validate POW, or set things up so that sketchy deoptimizations games were needed.)

The cause for my interest in this technology is pretty well established, https://bitcointalk.org/index.php?topic=279249.0  https://bitcointalk.org/index.php?topic=321228.0  https://bitcointalk.org/index.php?topic=277389.0 https://bitcointalk.org/index.php?topic=398041.0 etc.  I've been developing cryptocurrency tech for personal and philosophical reasons for eons (in cryptocurrency time) and perhaps you're too busy with sleezy speculative activities to notice that there are some other people who are involved for reasons which are unrelated to making a quick buck.  There are more things in heaven and earth than are dreampt of in your philosophy.

(As an aside— you probably should be pretty happy that I went and pointed out this tech in discussions about ZeroCash, regardless of which forks you support I'm sure you benefited from it whereas I did not (in fact, I've not even managed to get any real thoughtful tech discussions out of it— few to none of the people posting here seem to actually understand the tech, and instead everyone is just flinging poo about their favorite forks).  Perhaps in the future I should not forget to add the caveat that while the tech is neat and deserves more attention, like most altcoins the community is full of speculators who actively repel technical folks with wild accusations stemming from an apparent inability to understand that not everyone is so desperately greedy...  It's doubly hilarious, in that it's so thoroughly counter productive— I don't approve of the pump behavior and won't try to encourage it, but I certantly could bring a huge amount of attention to this space by pointing how how powerful the technology is to people— but I'm certantly less inclined to do so when simply speaking my mined gets me accused of being one of y'all coin pumpers even by the selfsame folks who would benefit from it.. I mean, wtf are you thinking? Were you raised by wolves?)

Yea, well the darkcoin thing was pretty offensive to me in general, I feel that it commercially exploited my work promoting coinjoin— itself not so bad, but it was frustrating that it was also stupid: the attraction of coinjoin— for all its limitations— is that you don't need a new coin, it's already just part of Bitcoin.  I've been continually disappointed by the level of hype around Zero*, especially when it comes at the expense of attention to other techniques which are very interesting themselves.