Like a party guest who wants to play gin rummy noticing a deck of cards sitting on your bookshelf and wanders into your study or bedroom or whatever private area to get them...

Well, that's where I thought the goal posts were.

Anyway, the coin selection policy *could* refrain from associating more than one past transaction with the current transaction whenever possible.  It'll always associate at least one past tx with any tx its making because those txIns have to come from somewhere.  But assuming that any past tx created txOuts equal to the current need, it can avoid linking *more* than one.  And if at some point the user bites the bullet and sends change too small to make another purchase with to a miner instead of letting the wallet aggregate it into a tx that links more than one past tx, that user would have multiple, separate, linked chains of transactions that never cross-linked with each other.   Which isn't real privacy, but it's a heck of a lot better than the current wallet does.

Well, they can if they don't care about making a payment quickly.  But they can sort of do that now.  A double spend of the same coins has a similar effect, given that miners will reliably select the version with higher fees given the choice, and the network will rapidly transmit a tx with minimum fees while it sharply limits the volume of tx with low fees. 

Given the amount of discussion we see about confirmation times already, I doubt it would be a major problem anyhow.


As I said, I'm experimenting here.  This stuff got left out of Bitcoin for reasons that are likely to be good reasons. Given the flak generated over the block size debate, I'd estimate there is a zero percent chance of this getting into bitcoin core within the next ten years.   I've made a very complicated attack surface by making "normal" tx that could not get included into both sides a fork or added to a fork after a reorg. There's likely to be a DoS vulnerability lurking in there somewhere, although I think the normal fork-resolution mechanism can take the strain.

I had a particular use case in mind with nSpendableHeight.  It's a way to give the user a choice about whether a tx is obviously unspendable until a certain height, (ie, anyone can tell it's unspendable until a given block) or whether that information should be kept private until the coins are spent and a script including a hypothetical OP_LOADCHAINHEIGHT is revealed.

That said, you have a point. when I think about the way scripts work in Bitcoin, I think you could also make the script stored in the transaction readable to make the spendable-height information public if you wanted to.   Either way, it adds a lot of CPU time to the job of checking transactions, because you have to connect additional context to tell whether a tx is valid.

I sort of like the idea of an alt that deliberately does things too dangerous for bitcoin just to see if anyone finds a real attack point.

Is that really what you got out of that whole explanation?  Darn, my communications skills must suck.

I'm not a miner.  I never have been.  I really do want to make a proof-of-stake system that works.  But getting past the initial part is hard, and that genuinely is my best idea for getting there. 

What I outlined winds up being a Transactions-as-proof-of-stake system; it makes the transition gradually, but that's where it goes.  Payments for block chain security, aside from the block subsidy which gradually fades into insignificance because inflation, are made to people in proportion to the amount of block chain security they provide  by using their stake in support of one version of the block chain instead of another. 

I proposed proof-of-work as a ramp-on because I don't think transactions-as-proof-of-stake will be "steady" enough to secure a block chain until you have thousands of people making transactions.  There's just too much variation in transaction volumes from one period to the next, so an attacker could force a split by making a really big transaction during a slow block.  Without something "steady" in the initial stages, you'd have to counter that variability with long block times to allow transactions to average out somewhat and give the inevitable forks time to resolve.  At least until you have a whole lot of people making transactions, and at that point the "miner" is living on tx fees plus what he gets by staking his own coins.

You could have a different ramp-on if you like.  Another possibility is copying the txOut set of an existing coin to make the initial distribution.   But distributing your stake payments to the people whose stake actually supports security means that the people who make transactions get almost all of it, and the people who form the blocks eventually wind up getting almost none of it.  So, as I said, it doesn't really matter how you decide who gets to form blocks.

I don't think that it is.  A transaction is an event that consumes inputs and creates outputs.  Those outputs later become inputs in another transaction.

Someone analyzing the block chain can see which TxOuts are being used as inputs in any transaction, which means knowing what transactions those TxOuts were created by.

When I make a transaction buying a peacoat from overstock.com, using both the change I got from buying alpaca socks a couple years ago and the change I got from a tx buying coffee that I paid for out of my paycheck - then someone looking at the block chain can see a transaction that links the transaction that purchased the alpaca socks and the coffee purchase to the peacoat buy.   If they go another level out, they'll see the paycheck - which is one output of a lot of similar-sized outputs all originating in the same place, so they can tell it's a paycheck - and they can see the coffee house, where all these similar-sized inputs from people buying coffee get aggregated and used for business-purchase sized items (and more paychecks).  So they can probably use that peacoat purchase to associate that ancient purchase of Alpaca socks to my current paycheck and coffee purchase, if they want to.

Okay....  With PoS as usually implemented, the "coin days destroyed" are the basis for selecting one chain over another.  So that's the "security" measure that people ought to get paid for providing.  But it is not what people get paid for providing.  They get paid for locking up coins, providing something else.  Something completely unrelated to the security of the block chain, because they can lock up the same coins on both sides of any fork.

Also?  "Coin days destroyed" are not a finite resource in the way that something needs to be finite in order to help secure a block chain.  Someone with 1 coin that's a month old should not be able to play for a 3-to-1 advantage in a game that nets him ten coins one day old.  Nor should someone be able to spend the same coin in both of two different forks to generate different priority in both just because the coin is spent at a different block chain height.  

"Total transaction volume" is also not limited in the way you need it to be limited for security.  If you have a system where an attacker can generate more priority for an attack chain by repeatedly shuffling his coins between different wallets after the fork, that's a broken system.

Also?  If an attacker can prepare a block chain without letting anyone else see it, which has comparable transaction volume, just by replaying other people's transactions that he sees on the main block chain into his attack chain?  That's also broken.  If it's a coin-days-destroyed system so by playing them into later blocks make his attack chain have more priority than the real chain?  That's even more broken.

The only real measure of stake that matters when picking between two forks of a block chain, which is limited in the way we need a security measure to be limited, is the amount of coins that existed before the fork, which are  used as inputs after the fork.  Even that is useless unless the transactions actually specify which side of the fork their stake supports by specifying the ID of a recent block and not being valid in any chain not derived from that block.  

So, a Proof-of-stake system that works looks like this:  Every transaction 'stakes' a recent block and is not valid in any block chain that is not derived from that block (so an attacker can't replay it into an attack chain that started before the stake block).  The choice between forks is made on the basis of which chain has more coins that existed before the fork and are used in transactions staked after the fork.  Because that's the basis of chain security, that's what users get paid for providing. And you do that by making them get interest on the coins they use as inputs in transactions, up to the stake block. 

If they stake a block that's not very recent, the transaction is valid in all possible forks arising after the stake block, so it's not very useful for security.  On the other hand, it's valid in all possible forks arising after the stake block, so they can be comfortably certain that whatever fork wins in such a split their transaction will be in it.  So they get the security payment interest up to the stake block, and the miner gets the security payment interest after the stake block.

Miners are motivated to include absolutely all the transactions they can find on the network because including all the transactions means their block has priority if a fork happens.  Miners will also make a transaction staking their own entire wallet every time they make a block, both to collect the interest on their coins and to generate priority for their block.  

But someone not using their coins to support any block chain is contributing nothing to security for that whole time, so there has to be a top limit on the amount of time people can get paid interest for.  Not too short, or you spam the block chain with transactions far too frequently made just for the purpose of not losing interest. But not too long, either, or you wind up with the whole burden of security sitting on the miners as people just sit there with their wallets not supporting either branch of any fork.  Let the rest of the stake interest go to the miners along with tx fees, because the miners are providing security for all the people who leave their coins sitting there.  

It doesn't matter how you decide who gets to form a block; I think proof-of-work mining is fine for that.  But, once again, the amount of security counted for a chain fork, should equal the amount of security the payment is a reward for, so if you have a block subsidy (and you should, to distribute a coin supply) then you have to count the miner's work, or whatever resource the miner irrevocably committed to his block that he cannot also commit to any forking block, toward block chain security too - in roughly the same proportion as the proportion of block subsidy to stake interest generated.  

My own preference is for the miner to get a constant block subsidy, which will start out being the whole money supply.  Hence the system works like a proof-of-work coin until coin interest/stake awards start to be generated. But if the system lasts, then the block award eventually pales into insignificance relative to the amount of stake income being generated, because compounding interest.  So it asymptotically approaches a system that works like a proof-of-stake coin. The transition is very gradual, but at that point the miners are basically living on transaction fees and stake scraps.

I believe the ideal is a PoW/TaPoS hybrid, eventually converging on Transactions-as-Proof-of-stake as the transaction rate gets large enough that any 'whales' big enough to game it for a double spend are also too big to do so and not get prosecuted.

Most implementations of Proof-of-stake suck.  They are not the way it's supposed to work, and the PoS stakers who forge blocks do not actually contribute security to the block chain in relation to their staking award.

Y'all seem to be ignoring the possibility that Satoshi does not give a crap about personal wealth.

I think there's a lot of people out here who've been listening to each other too much.  Bitcoin started with Engineering effort, mostly Satoshi's and Hal Finney's.  Other engineers joined the project and brought it to its present state. It was only after it started actually working that it became a "movement" attracting people for idealistic reasons - again starting with Hal Finney, but that part of it specifically did not involve Satoshi as far as I know.  And only after it became a "movement" did it wind up on the radar of the people who are just in it to make a buck - a cadre that Satoshi and Finney are both not a part of as far as anyone can tell.  

Satoshi's recorded posts are pretty silent on most of the Idealist stuff that's been associated with the "Bitcoin Movement".  Satoshi did not IIRC assume that all banks and all governments are inherently dishonest.  Hal Finney did, but I don't remember anything like that ever associated with Satoshi.  Satoshi was very much in favor of building a monetary system where certain types of dishonesty are flatly impossible, but he wasn't a revolutionary against banks and governments, he was just applying engineering skills to try to solve a longstanding human problem.

But the Bitcoin project attracted goldbugs because of its limited-supply, it attracted people who are fed up with governments and believe all governments are dishonest because of being a form of money that isn't government-issued, and it attracted people who are fed up with banks and believe all banks are dishonest because of allowing people to do their own banking without relying on banks and money transmitters.  And Hal Finney was a member of all three of those groups.  

And each of those three groups arrived with a certain number of people who had carefully considered, mostly moderate and fairly nuanced opinions on the matter, and a certain number of people who are, if you'll excuse me for saying so, raving conspiracy-theorist loonies who paint all banks and all governments everywhere as having been inherently evil throughout all of history.

And they brought the project up to a critical mass which attracted speculators who are just looking for a quick way to make a buck.

And all of these groups, it seems to me, have assumed that Satoshi shared all of their political views and/or aspirations to enormous wealth, when in fact he was so apolotical that no one can even tell what country he was from and apparently does not give a shit about making any money from the million-plus bitcoins that he mined back when he was the main reason the block chain was secure at all. 

For what it's worth, in its original form it went on to state that once somebody mentions Hitler, odds are that the thread is no longer worth reading. 

So, yah, count me as +1 for locking the thread.  It got stupid a long time ago.

Well, the market has to thrash the "tainting" question sooner or later. 

Time to make popcorn and pull up a chair...

And this surprises anyone why? 

OF COURSE crooks steal money!  If they didn't they wouldn't be crooks!

Hey, if she wants to go look at a webcam site, she can pay any way she wants.

The way the wallet selects coins to spend completely disregards which previous tx those coins originated in, so generally it winds up 'connecting' as many different previous transactions as the number of txOuts it uses to make a payment.  Recursion, rinse, repeat, and on a practical level anybody can build a record of all the transactions made by any particular wallet.

A more privacy-conscious wallet would take care not to use txOuts originating in more than one previous tx, and to use *ALL* the txOuts originating in that previous tx as inputs regardless of the amount owed, insofar as possible.  It would set a minimum amount corresponding to a smallest payment you ever expect to make, below which it would simply give change to the miner as a "fee" rather than getting it back in the wallet where it would eventually be spent along with a txOut from a different transaction.

In response to your question; privacy features aren't meaningfully implemented in Bitcoin yet. 

I've been experimenting.  

I hacked the Bitcoin 0.10 code to handle some extended attributes for transaction admissibility.  It seems to "work"  on my two-machine testnet, but I haven't really yet considered all the attack surfaces rigorously.

In transaction.h I added nLastTime to go along with nLockTime.  While nLockTime is the earliest block in which a transaction would be accepted, nLastTime is the last block in which a transaction would be accepted.  So that, if it hasn't happened by block height nLastTime, you can be absolutely dead certain that, absent a reorg that goes back before that block height, it will never happen.   Then I added IsAliveTx to go along with IsFinalTx and put calls to it in ContextualCheckBlock and IsStandardTx to make the code enforce it.

I added a new member variable named nSpendableHeight in the txOut, which gives a minimum block height which must be reached before a tx spending that output can be accepted into a block, and hacked IsFinalTx to check the inputs and make sure each has reached its spendable height.  It is not at all clear that nLockTime is needed at all if nSpendableHeight is implemented, but I haven't gone to get rid of nLockTime yet.  

In txIn, there was a variable named nSequence, which was connected to an old scheme for transaction replacement that was never implemented, in part because it was a bad idea.  nLastTime allows a tx in the mempool to be replaced (after it could no longer be included in any later block in the block chain) so it wasn't needed and I got rid of it.  

Each of these required a whole bunch of changes in serialization stuff, but that's not all that important.  

Currently, which tx are admissible in a given block depends on which tx have been in previous blocks and which other tx are in the current block, and, in a nonstandard tx, on the block height being at least the nLockTime minimum.  With the changes I added, it also depends on the block height not having exceeded a given nLastTime and on the txOuts that the tx is trying to spend all having reached their nSpendableHeight.  

.....

So I can now make a transaction that pays someone 100 testcoins, but in 10 different txouts of 10 testcoins each, which become spendable at different block heights corresponding to one payment every two weeks for five months.  The receiver  can prepare tx in advance that spend those coins, but the tx won't become valid to include in a block until the coins become spendable.  

So he could make a tx spending one of those outputs, hand it to somebody he owes money, and once the txOut becomes spendable the creditor could broadcast the prepared tx and get paid.   This is approximately the same thing that any "useful" implementation of nLockTime does, so I think nLockTime is truly redundant and probably ought to be removed given an nSpendableHeight on a txOut.

And I can also make a tx that spends 10 testcoins to a given address IF AND ONLY IF it is mined prior to a given block height - and once that block height passes, be absolutely certain that that tx will never get into any later block, so spend those 10 coins in a different way with absolute confidence.  

One issue is that in a reorg, transactions that were valid on one side of the fork cannot necessarily be included on the other side of the fork.  This makes confirmation depth much more important in this test chain than it is in current Bitcoin code - and also makes it more compute-intensive and messy to correctly handle tx in the event of a reorg;  you could wind up with a lot of tx in the mempool that will never become valid on the new branch.

As yet I've only provided ways to specify these values using the RPC interface; hacking QT is its own pain in the arse.

I've thought about this...  and not really reached a significant conclusion.

I worry when I get silly time stamps.  It could mean somebody is trying to so some kind of timing attack.  I mean, it doesn't normally mean that, and I'm not aware of any history of such attacks that have been made specifically against Bitcoin, but ....  well, I worry about stuff.

It would make sense, sort of, if nodes did not relay blocks whose timestamp is before the node's local time.  But if that were the case the network would sprout a new attack surface where nodes whose clocks were a minute late or a minute early could be forked off from the rest of the network, possibly for sequences several more blocks deep. 

So tolerating the occasional silly timestamp seems like the lesser evil.

 

I have an "if everything goes to hell" bag.  It contains some basics - MRE's, water filtration stuff, fishing hooks and line, matches (in waterproof container), candles, fish net, some protective clothing, field guide to edible/poisonous plants and wilderness survival (printed on paper, in waterproof bag), first aid including snakebite kit, crowbar for clearing rubble/breaking out of rubble, toolkit, replacement bits for things likely to be damaged by certain kinds of disasters or disabled by people's mistaken responses to disasters, radio, hand-crank recharger ....  and, oh yeah, some cash.  

I hope to spend the remainder of my life without needing to grab that bag in a real emergency, but ...  well, it would be kind of dumb not to have one.

As amusing as it is to see some idiot mistake Adolf Hitler for a socialist.....

I think we had reached the Godwin Limit long, long before this normally-reliable indicator appeared.

This is bluntly wrong.  Read the 'agnostic/dgaf' votes as people who will go with whatever works and wins.  If the code for a fork is deployed, they'll go right on mining - possibly with new software that advertises a new block version, or possibly without updating.  If their client tells them that the majority of blocks out there are a new version and they risk being on the losing side of a fork if they don't upgrade, they'll upgrade, 'cause they don't want to be on the losing side of a fork.  If the software they upgrade to advertises a new block version, they don't give a crap but that could easily push support from 50% (where they got the warning) to 75% (where a >1Mbyte block can actually be formed).

And if they find themselves on the losing side of a fork with majority hashing power already supporting a different chain, they will FIX THE PROBLEM immediately by updating. 

'agnostic/dgaf' means that a choice between these options is not going to be the motivation that causes these people to do anything.  A risk of being on the losing side of a fork would certainly be a motivation they'd respond to.  Having some other reason to upgrade to the next version (or just upgrading because upgrading is "normal") is also something they'd do.  They just don't give a crap whether, by so doing, they choose one block size limit or another.

Wait.  When you say the "original paper" are you talking about the one he put up in November 2008?  He put a link to it on the crypto mailing lists, but the paper now at that link is a slightly later version?  That one?

'Cause I've got that one saved on my hard drive.  There's really not much difference from the one that's there now except a few sentences have been straightened out for clarity.

Send me your edress and I'll shoot you the file.