 Show Posts
|
|
Pages: [1]
|
Charlie Lee said the following on reddit. I know this issue has been discussed a lot, but what are the models and calculations for a floating fee model? I know satoshi was very aware of this problem, but baking it into the algorithm would have been very hard to do. How do coin users know that the price is fair if the mining oligarchs engage in price fixing? there is no way to tell what the trust costs are. Satoshi made mining last many many years before transaction fees take over. This is because he knew that it's not sustainable otherwise. http://www.reddit.com/r/dogecoin/comments/22hqm6/official_an_update_on_the_foundation_core/Satoshi's quote with the 0.1 release:
When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.
|
|
|
|
|
the following is a speculative idea. I wonder whether it would be possible to produce physical coins which have smart properties (smart contracts + physical coins). What I imagine is a physical coin, with some CPU in it, and perhaps other sensors like GPS. Something like a cheap tailor made cell phone for holding Bitcoins. One could use it like cash, but it would have some advantages. For example it could have a physical color and that color would change depending on the value. At first it would be somewhat of a gimmick, but could be actually useful in special scenarios: for example keys in a hotel or chips in a casino. my reasoning is that while mobile phones are very good for holding Bitcoins, they can't be physically transfered. in that sense smart coins would not only represent of the value of the coins, but the keys as well. of course in Bitcoin transfer of wealth is a chain of signatures and transferring keys is almost never a good idea. with smart coins one would transfer the value with the keys (they would not be transmitted to the blockchain). one would not only transfer wealth, but everything that is attached to these keys, for example the right to open a door.
|
|
|
|
As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose
and one special, magical property:
- can be transported over a communications channel
If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.
Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.
I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.
(I'm using the word scarce here to only mean limited potential supply) https://bitcointalk.org/index.php?topic=583.msg11405#msg11405Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.
The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
While this system does not guarantee the parties against loss, it takes the profit out of cheating.
If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.
Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
https://bitcointalk.org/index.php?topic=750.01) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat. https://bitcointalk.org/index.php?topic=1790.msg29159#msg29159I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage? If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it. Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it. Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it. Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related. There's something here in the general area: http://www.users.zetnet.co.uk/hopwood/crypto/rh/What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m. When paying to a bitcoin address, you would generate a new blinded key for each use. Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it. As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it. |
|
|
|
I'm wondering which other avenues for bitcoin discussion exist and how active they are. By volume bitcointalk and reddit are huge. hackernews features bitcoin news regularly. Adam Back lists the following mailing lists. also see this part of interesting history: https://bitcointalk.org/index.php?topic=225463.0 The cypherpunks mailing list
The cryptography moderated crypto mailing list (mostly low social significance tech discussion) archive
The coderpunks list is dead try the cypherpunks-moderated list. (Old coderpunks archives can be found here archive)
bluesky global-scale distributed storage mailing list bluesky
The p2p-hackers list
The steganography mailing list
The ukcrypto mailing list, crypto politics in the UK http://www.cypherspace.org/adam/ |
|
|
|
2 years ago an expert in SSL security - Moxie Marlinspike - proposed an alternative to CA's - notaries, a kind of reversed certificate authority. the project is called convergence. It hasn't taken off yet, but the idea is very much worth pondering. https://github.com/moxie0/Convergencedefcon talk http://www.youtube.com/watch?v=pDmj_xe7EIQDiscussion with Whitefield Diffie: http://www.youtube.com/watch?v=lt7uW6vDk00Contrary to the beliefs of some bitcoin core developers I think CA's are thoroughly broken, and the use of them makes bitcoin worse, not better. SSL was a quick hack by a netscape engineer 20 years ago. |
|
|
|
pipa's suggestion for fixing some issues, which are related to MtGox statement from 2/10/2014. Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9 and BitcoinJ already implement it, though) and potentially invalidate some script functionality. However, these new rules remain optional and controlled by an nVersion increase. Comments please! This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).
==Abstract==
This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).
==Motivation==
As of februari 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys.
This is a problem for multiple reasons:
* The sender may not recognize his own transaction after being modified.
* The sender may create transactions that spend change created by the original transaction. In case the modified transaction gets mined, this becomes invalid.
* Modified transactions are effectively double-spends which can be created without malicious intent (of the sender), but can be used to make other attacks easier.
Several sources of malleability are known:
# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
# '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
# '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_DATAPUSH, OP_DATAPUSH2, OP_DATAPUSH4). As the later ones have the same result as the former ones, they result in additional possibilities.
# '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
# '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
# '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing.
The first six can be fixed by extra consensus rules. The last two can't, but are always under control of the (original) sender.
==Specification==
===New rules===
Six extra rules are introduced, to combat exactly the six first sources of malleability listed above:
# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). To convert another signature, simply take the complement of the S value (modulo the curve order).
# '''Non-DER encoded ECDSA signatures''' All ECDSA signatures must be encoded using strict DER encoding.
# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the result is invalid.
# '''Non-push operations in scriptSig''' Any non-push operation in a scriptSig invalidates it.
# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation (including OP_0 for an empty byte vector, or the direct pushes of a single byte) must be used when possible. Using any push operation that could be encoded in a shorter way invalidates it.
# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed.
===References===
Below is a summary of the effects on signatures, their encoding and data pushes.
====Low S values in signatures====
The value S in signatures must be between 0x1 and 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 - S.
The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 (inclusive).
====DER encoding====
For reference, here is how to encode signatures correctly in DER format.
0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [sighash-type]
* total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.
* R-length: 1-byte length descriptor of the R value that follows.
* R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
* S-length: 1-byte length descriptor of the R value that follows.
* S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).
This is already enforced by the reference client as of version 0.8.0 (only as relay policy, not as a consensus rule).
====Shortest possible data pushes====
For reference:
* Pushing an empty byte sequence (or the number 0) must use OP_0.
* Pushing a single byte sequence of byte 0x01 through 0x10 (or the numbers 1 through 16) must use OP_n.
* Pushing the byte 0x81 (or the number -1) must use OP_1NEGATE.
* Pushing any other byte sequence up to 75 bytes must use the normal data push (opcode byte n, with n the number of bytes, followed n bytes of data being pushed).
* Only pushes of more than 75 bytes can use OP_DATAPUSH.
* Only pushes of more than 255 bytes can use OP_DATAPUSH2.
* OP_DATAPUSH4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using OP_DATAPUSH2.
==Compatibility==
'''Version 3 blocks and transactions''' To introduce these new rules in the network, we add both nVersion=3 blocks and nVersion=3 transactions (nVersion=2 transactions are skipped in order to keep the version numbers synchronized).
'''Relay of transactions''' A new node software version is released which makes nVersion=3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of nVersion=1 transactions is unaffected. An nVersion=1 transaction spending an output created by an nVersion=3 transaction is also unaffected.
'''Block validity''' In addition, the same mechanism as in BIP 0034 is reused to introduce nVersion=3 blocks. When 75% of the past 1000 blocks are nVersion=3, a new consensus rule is activated which requires nVersion>=3 transactions in nVersion>=3 blocks (and only that combination) to follow the above rules. An nVersion>=3 block with an nVersion>=3 transaction whose scriptSig does not follow the new rules, becomes invalid. When 95% of the past blocks are nVersion>=3, nVersion=2 blocks become invalid entirely. Note however that nVersion=1 transactions remain valid forever.
'''Wallet updates''' As nVersion=3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but setting nVersion=3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software.
|
|
|
|
altcoins.cc altcoins.cc is an opensource portal to alternative cryptocurrencies. currently featuring 140 altcoins with cryptsy and bter listing information. pull requests welcome.
. . TODO add a column for the algorithm (proof of work, proof of stake, ...) add a flag for clones add a tier for announced coins consider donations/bounties |
|
|
|
say an organization friendly wants to take a donation. what they can easily do of course is they post their btc address on their website friendly.org . however, the address can be changed, because the website can be changed. public orgs like greenpeace will probably not do that, but the imagined friendly org is a small org with little trust. the question is how to create a mechanism so that friendly can prove that the address has not changed. such a mechanism is wanted, because then the address acts like a fund. that is all inputs and outputs can be tracked. funds can't be misappropriated as easily. with an unproven addresses one can claim that the balance is lower than it actually is. it doesn't have to be 100% secure at first, but reasonably secure. here is a simple adhoc solution which can serve as a discussion. to my knowledge this has not been done yet. friendly posts an address in a thread on this board with the title "address proof" with the message PING addr #1234 tag friendly 1 or several people reply with PONG addr #1234 tag friendly This would work for small message loads. Anyone who wants proof can go through the thread and find the post. The PONG message can't be forged by PING unless PING corrupts PONG to change his post. if several people reply he would have to corrupt each of them. A more involved protocol could be: PING addr #1234 tag friendly 1 or several people reply with REQ addr #1234 tag friendly reqaddr #5678 0.01 BTC If PING sends 0.01 BTC to #5678 the requester will PONG PONG addr #1234 tag friendly With this kind of protocol the message load would become to much. it can be done on a separate system for large loads. Edit: an even simpler solution would be if the message board itself would have a mechanism for a 1:1 relationship between member and btc address, which acts as a central party. I'm not sure what the current protocol is with regards to bitcointalk and the address some members provide.
. more generally before the blockchain there was no way to prove that things have existed on the internet. the blockchain is not meant to be a record store for arbitrary storage. namecoin comes closer to such a solution as it is build around lookups. the domain system of the internet is a specific lookup mechanism which is not concerned with historic records. there are possible solutions for this discussed mechanism which are not trivial to implement. see: http://wikileaks.org/Transcript-Meeting-Assange-Schmidt.html#731https://bitcointalk.org/index.php?topic=53855.msg642768#msg642768Edits: simpler solution clarify fund aspect typo |
|
|
|
|
