The timestamp at offset 4 (bytes 4 - 7 in the last block) either can't move, or must become an added nonce field, because existing hardware is modifying that location in order to extend the nonce range already, resulting in timestamps on mined blocks that are inaccurate by up to 256 seconds. Nothing else (except another nonce field) could be modified in that way without destroying the validity of the block.
My idea was to leave only the two least significant bytes of the time there (the nonce2 field) since I don't think the hardware take more than two bytes of the field for nonce (random) purposes. I don't think the hardware uses the time field to keep up with the time. It may use it to add more nonce space. The difficulty field at offset 8 (bytes 8 - 12 in the last block) can't move because that's the location that existing ASICs read in order to find out whether the hashes they're coming up with are low enough to win or not.
I don't know a lot about the hardware but I think the difficulty should be read and interpreted by the software, and then sent to the hardware in a more machine-friendly way, such as the number of preceding zeros. Are you sure it is the hardware that interprets difficulty? |
|
|
|
Hi! I wish you take a look at a new protocol I proposed to achieve high block rates and tell me your opinion. I think it competes or maybe outperforms the GHOST protocol, but I have done no simulations to verify it. I will test it in my http://NimbleCoin.com cryptocurrency and see what happens. This is my post: http://bitslog.wordpress.com/2014/05/02/decor/Best regards, Sergio. |
|
|
|
We'd proposed something like this in P2Pool a while back— at least the basics of it: announcing key in share and doing threshold cryptography so that larger p2pool miners could automatically peer with similarly sized miners— there are some obvious shortcomings that come up like even if you assume a large miner will keep the data secret out of self-interest they may not be a large miner forever: once a large miner is no longer a large miner they don't have as much reason to keep the data a secret.
You could constantly re-share new introduction keys to end leaking, but knowing the miners address alone is enough to DOS attack it. This kind of approach also doesn't address the issue large miners often suspect other large miners of being a perpetrating attacker, e.g. delegating your peering to a hopefully neutral third party can make business sense. I guess you do accommodate that by virtue of the miners being able to choose the addresses they share, allowing them to instead delegate a third party at that point.
As you said, if the protocol is automatic, the addresses (or a secret random key required to establish the connection) can be renegotiated once a day or once a week, to prevent abuse after the hashing power distribution changes. Also if you give a different IP address (or a secret key) to each of your competitors, you can monitor any DoS attempt and prove who is behind it. And this is evidence that you can take to a court. I guess these reasons along with a lack of visible attacks on P2Pool, the ease of the manual peering method, and the complexity of implementing something like this is why it hasn't been done so far... but its good to see someone thinking out more of the details.
Threshold cryptography would probably solve the problem better, but probably requires a more difficult setup phase and a more complicated implementation. 1% ownership commitments can solve the problem practically and requires no complex crypto to prove correct. I agree that today there may be no need for an automatic backbone. But currently we have a miner with 32% of the hashing power that does not show a visible identification, which prevents anyone from contacting it directly. If there is a single secret miner, then this miner can still connect to all non-secret ones. The real problem would be if there were two secret miners. |
|
|
|
Hello everyone! The need for direct connection between the main miner pools or solo-miners (which is often called the miner backbone), was discussed several times in the forums. A miner backbone provides not only benefits to the network as a whole, but benefits for those miners that establish such connections. A backbone decreases the chances of blocks being orphaned, so miners also have a strong incentive to have direct connections between them and announce a solved block as soon as possible. I tried to create a protocol to allow the top miners to establish such a backbone automatically, without allowing the rest of the nodes to discover the top miners IP addresses. The full idea is on my post here: http://bitslog.wordpress.com/2014/04/19/the-private-automatic-miner-backbone-protocol-pamba/Best regards, Sergio. |
|
|
|
I can't imagine anyone complaining because the block interval is too short, if Satoshi had chosen a 1 minute block interval. Can you imagine a dialog like this in an hypothetical world where Satoshi had chosen a 1 minute block interval? - Ohh, I get confirmations too fast, it gets on my nerves! - Yes, I hate paying so fast. If Satoshi had chosen a 1 hour block interval instead of 1 minute I would think twice before buying such low quality products I bought yesterday. - Everyone is using it to pay at the retail stores, and that's very bad for online shopping. That's against the future we dreamed! - Could we fork the coin and make it much slower? - Wow! We could create a whole community that seeks laziness and less productive work around a new coin! Then WE could get millions! - Let's call it BitSlow. Out slogan should be "the cryptocurrency with 1 hour block interval that protects you from compulsive buying disorder" Sincerely, there is no reason, with the knowledge we have today, not to reduce the block interval with a hard fork instead of increasing the block size. It's possible to reduce the interval down to 5 seconds without any practical drawback, as it is explained in my blog post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/Best regards, Sergio. |
|
|
|
|
I always thought that if Satoshi burned 1 satoshi from one of his addresses the market would react positively.
He waits until everyone notices it, and then spends 1 satoshi.
Then he burns 2 satoshis, wait, and spends 2 satoshis.
Next day burns 4, wait, spents 4.
Keeps doing it until everyone is sure he is not going to dump all those coins in the market, just spend a few.
Regarding Satoshi's coins, I also concluded that block 9 was the only block reward Satoshi spent.
Best regards, and happy chain-archeology day!
|
|
|
|
Hi every one! This is what I did this week: the MinCen Protocol. The idea is design a cryptocurrency that behaves like a centralized one, but can disperse into fully distributed one if something goes wrong. Nature has many examples of colonies that have a queen, but if the queen dies somehow manage to re-elect a new queen that all obey. This is what the MinCen protocol tries to do: it chooses a master node that decides which is the next block when there are competing chains. Everyone then follows this decision. But if the master node tries to cheat then every miner starts looking for another master node, in such a way that individual decisions converge to a new global selection. Are you designing a new cryptocoin? give a try to the MinCen protocol The paper and some additional comments are available in my blog here: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/Best regards, Sergio. |
|
|
|
|
My suggestion:
Create a new opcode:
PUSH_SIG <n>
Which pushes a signature on the stack, where the signature is taken as the n-th element from a vector that is appended to the transaction but it is not part of the transaction hash. So transaction inputs are left IN the transaction, but signatures are NOT.
|
|
|
|
|
As I researched some time ago "Satoshi" pattern has a distinctive restricted nonce LSB range, and that's the reason why we see Satoshi pattern to be steeper than the other patterns. But also the pattern is more dense than it is expected, meaning the computer had several threads working on the same ExtraNonce incremental sequence, which suggests something like a special mining rig consisting on a master thread managing 5 child dumb threads, in a quad-core computer.
Regarding having access to the private keys, we know that the generated coins in block 9 (which seems to be part of the pattern) were used to pay for Hal's transaction. I inspected the pattern by eyesight and concluded that never again the coinbase of a block from the Satoshi pattern was spent. For me, this is a clear indication that he wasn't going to use that coins to manipulate the market or he purposely destroyed the keys to access the coins.
After all this media circus we've seen this week regarding his real identity, I suggest we take into account people's privacy. We researchers also make mistakes.
My own research was motivated by the need to understand the market in order to decide if I should invest in Bitcoin or not. And from that day I know that I should have invested more.
Have a nice chain-archeology day...
Sergio.
|
|
|
|
|
Sorry for the noise, but I will keep posting in this thread until we collect 30 votes or the admins take any action (which I hope it will be the most voted option)
Currently votes are 9:1 to split this forum into sub-forums.
|
|
|
|
no, there's already too many subforums to wade through on this forum. i don't have time to open tons of tabs all the time.
But why would you open all the tabs? Just open the ones that meet your interests, as everybody else. If there are more subforums, then you will actually need to read LESS post to find the ones that interest you. |
|
|
|
|
The forum is the greatest source of information about cryptocurrencies that exists in the Universe.
There are probably tens of thousands of post, but sadly there not well categorized and finding information regarding a certain subject has become too difficult. Academic papers skip adding references to this forum because of the same reason. The same ideas are re-posted over and over again with an average inter-post interval of 4.37 weeks. Also the number of post a day currently is so high that post get kicked out of the first page in the same day they are published and very few people has a chance to read them. I'm pretty sure the moderators cannot read them all now.
Last, some of us like some subjects a lot (such as Security in my case) but have no interest in other subjects (such how to compile the Saoshi client for the Commodore 64), so a sub-division help us use our time more efficiently to answer posts.
Could the admins subdivide this forum into new sub-forums?
Could the admins do a manual or automatic procedure for sub-dividing past threads on this forum into sub-forums?
sub-forum could be:
1. Scripting language and contracts
2. Lost / Corrupted Wallets
3. The block-chain
4. Block interval
5. Security
6. Privacy
7. Satoshi Client compilation/porting
8. Satoshi client releases
9. Core cryptocurrency improvements
10. Importing /Exporting data from the Satoshi Client
11. RPC commands
...etc...
If it cannot be done in retrospective, then we could create the subforums now and start doing it from now on...
(I offer to do an automatic subdivision of past threads, as long as the admins provide me with an spec on how messages are stored and provide me with a backup file)
Best regards,
Sergio.
|
|
|
|
The biggest issue is that these incredibly short block intervals will lead to tons and tons of orphaned blocks. Network speed/latency will become a pool's limiting factor, not hashrate.
So you are saying that he is lying when he says: -snip-
still keeping the coin safe from stale blocks and competing chains.
-snip-
 Well, I cannot claim that I implemented the whole thing, bought 60K servers around the globe, and tested it. What I'm saying is that I simulated it, and it seems to work. Simulations of LiteCoin and Bitcoin agree with the empirical evidence of stale block rate, so I suppose the simulation of FastCoin5 is correct too. |
|
|
|
Here is my last article regarding how a PoW base cryptocoin can achieve a 25 second confirmation time using a 5-second block interval, and still keeping the coin safe from stale blocks and competing chains. http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/I think this is the first time such a short block intervals is studied. The techniques I used are not new, but I've managed to simulate the network and convince myself that it actually works quite fine. I'd love to hear comments... |
|
|
|
After some time, I'm reading the reference implementation in order to document what is the block forwarding logic, which I have forgotten. But the logic is spread all over main.cpp. Could anyone with deeper knowledge answer these simple questions with true/false? a. An orphan block received from a peer is not announced to the remaining peers until the parents are found ("inv" command not sent immediately). b. A stale block (not in the best chain) received from a peer is not announced to the remaining peers until it becomes part of the best chain ("inv" command not sent immediately). c. Some blocks are forwarded even if they are not requested by peers ("block" command issued even if "getdata" not received). Which blocks? d. Orphan blocks can be requested by peers using "getdata". e. Stale blocks can be requested by peers using "getdata". f. Nodes request whatever block it's announced by a peer "inv" command for which they don't have the hash, being stale, orphan or invalid. Assuming that three Satoshi nodes are connected, what would be the interaction between these nodes regarding received orphan, stale and best-chain blocks? This link https://bitcointalk.org/index.php?topic=41729.0 describes the interaction, but.. can it be described in more simple words? I think this information is useful for anyone trying to understand how the actual protocol works. Best regards, Sergio. |
|
|
|
 17mcFB7Xyymd9hxp2bgNPz1ruWsdoPoCnZ |
|
|
|
|
Show Posts
