|
Cryddit, did you read the op? Blind signatures require no honest nodes.
|
|
|
|
|
Pure proof of stake is a lie - there is in fact nothing at stake. This completely inverts incentives and makes the pure PoS protocol both trivially simple and profitable to attack (as someone will eventually do to NXT).
Hybrid proof-of-stake/proof-of-work a la peercoin waters down the security properties of pure proof of work and exposes a larger attack surface, thereby weaking security overall.
There's a reason pure proof-of-work and SHA-256^2 were chosen for bitcoin in 2009. Those reasons are still valid today, and that's why Freicoin is and will remain pure proof-of-work with SHA-256^2.
|
|
|
|
I've pushed a hopefully final version of the error correction coded normative transaction ID branch to my public repository: https://github.com/maaku/bitcoin/tree/normtxidThis version breaks behavior from what is described in this pull-request by using the regular (not SignatureHash) transaction ID for coinbase transactions. At this time I cannot imagine why you would need a normalized transaction ID for a coinbase transaction. But just because I can't imagine a use doesn't mean there isn't one, and services indexing the block chain need to make a decision about this edge case. The patch in this pull request has the potential to result in duplicate ntxid's for coinbase transactions since the coinbase string which contains the BIP-34 block height is a scriptSig and therefore stripped from the normative data structure. Additionally, the code now provides error correction coding for arbitrary length base32 strings, and complete coverage with a suite of unit tests. It also corrects two bugs that were found in the encoding algorithm, which were uncovered in the process of writing the tests. All that remains to be done is to write a BIP documenting its inner workings. |
|
|
|
I've pushed a hopefully final version of the error correction coded normative transaction ID branch to my public repository: https://github.com/maaku/bitcoin/tree/normtxidThis version breaks behavior from what is described in this pull-request by using the regular (not SignatureHash) transaction ID for coinbase transactions. At this time I cannot imagine why you would need a normalized transaction ID for a coinbase transaction. But just because I can't imagine a use doesn't mean there isn't one, and services indexing the block chain need to make a decision about this edge case. The patch in this pull request has the potential to result in duplicate ntxid's for coinbase transactions since the coinbase string which contains the BIP-34 block height is a scriptSig and therefore stripped from the normative data structure. Additionally, the code now provides error correction coding for arbitrary length base32 strings, and complete coverage with a suite of unit tests. It also corrects two bugs that were found in the encoding algorithm, which were uncovered in the process of writing the tests. All that remains to be done is to write a BIP documenting its inner workings. |
|
|
|
|
Of course they can be spent (provided Satoshi kept the key). The genesis coins can't be spent because of an entirely different issue: due to a (presumed) bug, the genesis transaction is not included in the coin database.
|
|
|
|
|
Or, like Eligius, they can reason that spamming the network with data is uniformity bad for everyone and an externalized cost that is not properly accounted for, and reject all data transactions on principle, for the health of the network.
|
|
|
|
|
A transaction's nVersion field may be set to any value. I don't suggest writing code that does so, however, as you place yourself at risk against future soft-fork changes which give the nValue field meaning.
|
|
|
|
Wouldn't the more obvious thing to ask for the customer's target address, not the TXID?
You're involving assumptions about the type of transaction, the customer's usage of their target address (address reuse is sadly a fact of life), and the scenarios under which a non-malleable txid is useful. This is an attempt at a more generic solution. Anyways, does this ID really have to be THAT unique? Why not a 32-bit hash like CRC32 or ADLER32 and just have the helpdesk look through the handful of transactions that have this hash in the mempool/last 3 days of blocks currently?
If that's all you need, then you can take a small hash over the normalized txid to get whatever it is you want. Again though, there's many applications where a truly unique ntxid is required, and a 32-bit checksum wouldn't deliver that. |
|
|
|
|
Eligius does not accept OP_RETURN outputs.
|
|
|
|
Maybe you could do something with uppercase lowercase instead? Capitalise every first, fifth etc letter? Or alternate blocks of four uppercase with four lowercase letters.
I thought about that, but I don't think it would be obvious to every user that the case sensitivity is merely for display purposes. By using one case uniformly the user doesn't feel prompted to qualify with "big"/"little" or "capital"/"lowercase". It's also less reliable as a visual distinction since there are non-cased digits thrown in as well. |
|
|
|
|
Well it does work in Chrome on Android. I wonder if it works in iOS? (I don't have a device to test). Since the concern is mobile users, maybe that is enough.
|
|
|
|
|
not on my browser (Firefox)...
|
|
|
|
|
Because it's cheaper to spend/invest than the exchange to get rid of it (exchange fees can be months of demurrage). This has been covered in depth: please read the thread.
|
|
|
|
Maybe add some dashes every four characters to make it easier to keep track of where you are in the txid when you're reading it aloud?
Actually the first version had just that - but with groupings of eight instead of four. Visually it looked good, but the feedback I got was that it would be hard to select in order to copy-paste, especially on a tap-to-click mobile device. Although making it easier to read over the phone is a design goal, it probably shouldn't be at the cost of a more difficult copy-paste, since I imagine that is the more common scenario these days. But that does remind me: I should make the decoder accept and ignore hyphens, so people are free to use that in their own systems when it makes sense. |
|
|
|
Thanks sundance! I just pushed code which adds unit tests, and enables error code protection for arbitrary-length base32 strings. I also just realized I forgot to demonstrate what the new ntxid looks like. Here's the ntxid for 6988d5fd2735b86e005ee9249a8b8053c91cd31fd1bfeadcf678093d1b710223: txbtsogbjjuimfqas7sgkbaqqkjxygyixk3deuxmrm1uqte8nukemm6yxujjjzbr |
|
|
|
|
You have to do something custom to put data on the blockchain anyway. And using OP_RETURN is easy: put the opcode (0x6a) in the front of the script, and increment the length prefix.
|
|
|
|
That's not entirely true. The Bitcoin developpemers is an organic movement. There are indeed no "appointed" leader, but still, people contributing often gain trust of the developpers, and become de facto leaders. But it is all based on trust. They -cannot- push changes by themselves, because change is based on concensus. But the opinion of those "leading" weight more in the balance. That's why most changes are coordinated by the Foundation.
But it is similar in many open source movemens. There are hundreds of Linux distros, that have forked from each other over a dissagreamenet on how to do things. Some are much more popular than the others. Still, Linus Torvald's opinion is more "trusted" than the average programmer, because he started it, the same as Satoshi has started Bitcoin.
Sometimes the lead can change entirely. Most of the developpers of OpenOffice dissagred with the "lead" a few years ago, so the all forked the project and started "libreoffice", which is now the de-facto open office suite.
No single developer can push a new release version. It takes the actions of at least 3 developers and widespread consensus for this to occur. Bitcoin is not like Linux: it's not lead from the top. |
|
|
|
|
Show Posts
