可以认为这是他希望的目的，不过他这样做应该失去了部分币圈的信赖

有一部分钱包支持只读的地址,只要你倒入地址时不提供私密就变成只读状态.

blockchain.info网站有这个功能叫watch only地址.选择倒入地址,提供公钥就可以了.

the key is to be able to complete all the trades in near time to avoid slippage. Not risk free

on the topic of arbitrage I have considered this strategy before, eg cross exchange arbitrage.  The main sticking point I see is moving your fiat in the opposite direction in preparation for more trades.  There are fees and a time lag associated with this, that may make the strategy not an efficient use of capital.  The fiat problem is worst when all the arbitrages are always in the same direction.  anyone have any experience with this?

https://www.bitmex.com/

has leveraged trading on bitcoin derivatives. the liquidity is getting better there recently.

btw thanks for the tip on Poloniex, they hadn't been on my radar before.

I have been trying to work out their (non cynical) business model ever since I first heard about 21inc.  It has me stumped. I am still waiting for the light bulb moment.

for the un-enlightened amongst us, can someone summarize what an "alert key" would allow the holder to do? and what implications that would have

In general nodes should not implement this type of restriction as it has the potential to affect the integrity of the network.

However an individual node could implement this custom version of bitcoind, so that the node can still make a contribution to the network although it might not be 100% contribution all the time.

An easier method is to have a script that shuts down your bitcoind "bitcoin-cli stop", once your specified bandwidth runs out. This way you can run a standard node without any degradation of service right up to the point where you simply turn it off.

yes it involves an element of trust, just like a normal cheque.  a cheque is a promise to pay.  However the when the cheque bearer presents the cheque to his own bank to retrieve the funds, the funds might be spent, or might never have been sufficient in the cheque writer's account.

how to create this promise to pay concept in Bitcoin...

it will search for all prefixes contained in your input file.  the program just displays probability information for the easiest prefix, ie based on probability it expects to find the easiest one first, then the next easiest... it will keep displaying the next easiest prefix probability stats. as it finds each one it "removes" it from its list in memory.

It won't exist until a result is found

I am not sure how the sybil attack would work in this scenario.  I would have thought the lottery system would attract a large number of cheap nodes.  An attacker would find it difficult to get a useful proportion of nodes into the system to allow them to influence the network.  ie PoW requires more hashing power in order to get a useful proportion, whereas here actors would all be increasing their own node count.

I think the sheer number of nodes combined with inherent network latency would mean that forking would be rampant, and there would be insufficient time to identify the best chain and re-sync across the network.  The system would simply 'fork' itself to death 

bad English? Your English looks pretty good to me.  Are you pretending to be Japanese too?


'Proof of Raffle'?  Looks more like Proof of Luck to me.  How can you get consensus on who is in the raffle?  Due to network latency there are likely to be multiple raffles happening, so every block you have a fork.  Then how do you identify who is the final winning fork?  In Proof of Work the winner is the miner who did the most work to mine the block.  In your case how can you decide who is the 'luckiest'?

Any protocol in which all nodes need to know the entire state of the network will not work effectively and be subject to many attack vectors.

In addition if there is no cost for me to add extra nodes into the network to enter the raffle then I will spin up lots of virtual machines to increase my chances, so then we suddenly go to millions of nodes across the planet.  I would like to see how you can have consensus across millions of nodes across the planet for a raffle.

nodes only relay information, they don't create any new information.  So it is difficult for a node to get paid, unless it "billed" the network by sending a type of pending coinbase transaction out for miners to include in blocks, to solicit payment for its service.  problem with that is how would each node know the value for the transaction?  it cannot be a fixed amount as that would eat into the miner's fee as the number of nodes increased.  the value should be a percentage of a fixed amount, ie [fixed amount / number of nodes = amount per node], but in this decentralized system can all nodes accurately calculate this, or should the mining node calculate this?  imagine every block with 6000+ coinbase transactions?  I also haven't touched on the possible attack vectors for these solutions.

In summary paying nodes for their services in such a decentralized network has not been resolved from a technical perspective.

However! if we think outside the box for a second you will remember the "Proof of Stake" method used by some altcoins, as opposed to the "Proof of Work" method used by Bitcoin.  Generally under the PoS protocol people are only rewarded based on their stake if they keep their nodes running.  People with large stakes are rewarded sufficiently for keeping their node running.  I believe certain altcoins have implemented hybrid PoW + PoS protocols.  PoS is currently the only tested and proven method for rewarding node holders.

Good luck trying to get some type of PoS mechanism introduced into Bitcoin core though!  It would only be contemplated if the situation became much more dire than it is now.

 

the address in your signature contains 34.  If I remember correctly an address is 33-34 characters long.  There are no 22 character addresses. 

It's a newbie asking the question so no I don't think it is a joke.

the short answer is the addresses will not run out.

bitcoin is designed to have far far far more addresses than will every be required.  therein lies its security.

assuming the hypothetical, that there was a collision and you created an address that was already in use then you have direct access to any funds at that address (unspent outputs sent to that public key). However the probability of that happening is so low that it is impossible (see other threads for comparisons to atoms in the universe etc).  We are not talking about winning the lottery odds here, these odds are far far lower, more like winning the lottery in a trillion years type of probability.

Even if only 1% of bitcoin addresses were used up then bitcoin would be considered well and truly broken.

I agree with you that it is not a very technical question which is why I didn't post it here originally.  However after so many people eyeballing it but nobody answering it, I moved it here in desperation.

I did do a search but I didn't pick up anything that answered it, this small clue was well picked up by you.

It seems the conclusion is that coinbase.com took their name from this terminology included in the bitcoin client.

I am still interested in a reference where Satoshi or an early developer actually introduces and defines the term 'coinbase'. ie the original reference as to why it is called what it is.

This topic has been moved to Development & Technical Discussion as it is a more technical topic.

https://bitcointalk.org/index.php?topic=1154531.0

When a block is created new bitcoins are also created and assigned to the miner who found the block.  to my knowledge this is done by including what is called the "coinbase transaction" in the block.

The company coinbase.com was formed in June 2012, well after the invention of bitcoin, and Satoshi's white paper does not refer to any such 'coinbase transaction'.

Can someone with factual knowledge of how this came to be please enlighten us?

what I meant was what are the characteristics of the transaction that identify it unequivocally as a SharedCoin transaction?  Or is it just an educated guess that it is?

what do SharedCoin transactions look like? and how do they differ to other mixing service transactions?