Bitcoin Forum
October 23, 2017, 06:28:27 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 ... 344 »
201  Other / Meta / Re: traceroute collection on: April 22, 2017, 05:23:53 PM
I think you want to include some additional syntax after the -T

I get this result when I run this command:

The -T option is specific to the Linux version of traceroute, which is why I mentioned needing a Linux machine. It uses TCP SYN packets instead of ICMP packets. Maybe there are ways of doing the same thing on your version, perhaps by using the -P option.
202  Other / Meta / traceroute collection on: April 22, 2017, 04:20:26 PM
If bitcointalk.org does not load normally for you and you have a Linux machine available, it would be helpful if you would do the following:

 - Undo anything you did to enable connectivity, such as VPNs or host-file changes.
 - Run traceroute -T bitcointalk.org
 - Run curl ifconfig.co to get your IP address.
 - PM me the output of both of those commands. Note that I will share the output with the forum's ISP.

Thanks!
203  Other / Meta / Re: Timeout connection on: April 22, 2017, 08:05:35 AM
Does any of you know until when the problem will end? I have been getting updates from the Twitter account of Bitcointalk and at first it said it was a denial of service attack and the next hour Theymos said it is another unknown problem.

It's an ongoing DDoS attack. Eventually, the attack will either end or I will figure out how to mitigate it, but I currently don't have a time estimate.
204  Other / Meta / Re: Timeout connection on: April 22, 2017, 06:44:33 AM
Additional traceroutes would be useful from those still unable to connect normally.
205  Other / Meta / Re: Timeout connection on: April 22, 2017, 04:08:22 AM
See here for hosts file IPs and other info: https://pastebin.com/raw/EaKixQni
206  Other / Meta / Re: Timeout connection on: April 22, 2017, 01:05:06 AM
This is fucked up, DNS poisoning? What is the correct IP?

bitcointalk.org now has multiple A records. They're all correct. Tools like ping which expect only one will use the first one returned by the DNS server, which is random.
207  Other / Meta / Re: Timeout connection on: April 21, 2017, 07:59:52 PM
After I changed the IP, it happened again in about 30 minutes, which makes me think that it is in fact a DDoS attack which is getting clogged up somewhere between the interface between the US and the rest of the world.

Now there are several reverse proxies sitting in front of the server, each with its own IP address. How is this working for everyone? I can increase the number of proxies arbitrarily if necessary.
208  Economy / Auctions / Advertise on this forum - Round 207 on: April 21, 2017, 05:19:57 PM
The forum sells ad space in the area beneath the first post of every topic page. This income is used primarily to cover hosting costs and to pay moderators for their work (there are many moderators, so each moderator gets only a small amount -- moderators should be seen as volunteers, not employees). Any leftover amount is typically either saved for future expenses or otherwise reinvested into the forum or the ecosystem.

Ads are allowed to contain any non-annoying HTML/CSS style. No images, JavaScript, or animation. Ads must appear 3 or fewer lines tall in my browser (Firefox, 900px wide). Ad text may not contain lies, misrepresentation, or inappropriate language. Ads may not link directly to any NSFW page. Ads may be rejected for other reasons, and I may remove ads even after they are accepted.

There are 10 total ad slots which are randomly rotated. So one ad slot has a one in ten chance of appearing. Nine of the slots are for sale here. Ads appear only on topic pages with more than one post, and only for people using the default theme.

Duration

- Your ads are guaranteed to be up for at least 7 days.
- I usually try to keep ads up for no more than 8 or 9 days.
- Sometimes ads might be up for longer, but hopefully no longer than 12 days. Even if past rounds sometimes lasted for long periods of time, you should not rely on this for your ads.

Stats

Exact historical impression counts per slot:
https://bitcointalk.org/adrotate.php?adstats

Info about the current ad slots:
https://bitcointalk.org/adrotate.php?adinfo

Ad blocking

Hero/Legendary members, Donators, VIPs, and moderators have the ability to disable ads. I don't expect many people to use this option. These people don't increase the impression stats for your ads.

I try to bypass Adblock Plus filters as much as possible, though this is not guaranteed. It is difficult or impossible for ABP filters to block the ad space itself without blocking posts. However, filters can match against the URLs in your links, your CSS classes and style attributes, and the HTML structure of your ads.

To prevent matches against URLs: I have some JavaScript which fixes links blocked by ABP. You must tell me if you want this for your ads. When someone with ABP and JavaScript enabled views your ads, your links are changed to a special randomized bitcointalk.org URL which redirects to your site when visited. People without ABP are unaffected, even if they don't have JavaScript enabled. The downsides are:
- ABP users will see the redirection link when they hover over the link, even if they disable ABP for the forum.
- Getting referral stats might become even more difficult.
- Some users might get a warning when redirecting from https to http.

To prevent matching on CSS classes/styles: Don't use inline CSS. I can give your ad a CSS class that is randomized on each pageload, but you must request this.

To prevent matching against your HTML structure: Use only one <a> and no other tags if possible. If your ads get blocked because of matching done on something inside of your ad, you are responsible for noticing this and giving me new ad HTML.

Designing ads

Make sure that your ads look good when you download and edit this test page:
https://bitcointalk.org/ad_test.html
Also read the comments in that file.

Images are not allowed no matter how they are created (CSS, SVG, or data URI). Occasionally I will make an exception for small logos and such, but you must get pre-approval from me first.

The maximum size of any one ad is 51200 bytes.

I will send you more detailed styling rules if you win slots in this auction (or upon request).

Auction rules

You must be at least a Jr Member to bid. If you are not a Jr Member and you really want to bid, you should PM me first. Tell me in the PM what you're going to advertise. You might be required to pay some amount in advance. Everyone else: Please quickly PM newbies who try to bid here to warn them against impersonation scammers.

If you have never purchased forum ad space before, and it is not blatantly obvious what you're going to advertise, say what you're going to advertise in your first bid, or tell me in a PM.

Post your bids in this thread. Prices must be stated in BTC per slot. You must state the maximum number of slots you want. When the auction ends, the highest bidders will have their slots filled until all nine slots are filled.

So if someone bids for 9 slots @ 5 BTC and this is the highest bid, then he'll get all 9 slots. If the two highest bids are 9 slots @ 4 BTC and 1 slot @ 5 BTC, then the first person will get 8 slots and the second person will get 1 slot.

The notation "2 @ 5" means 2 slots for 5 BTC each. Not 2 slots for 5 BTC total.

- When you post a bid, the bids in your previous posts are considered to be automatically canceled. You can put multiple bids in one post, however.
- All bid prices must be evenly divisible by 0.05.
- The bidding starts at 0.25.
- I will end the auction at an arbitrary time. Unless I say otherwise, I typically try to end auctions within a few days of 10 days from the time of this post, but unexpected circumstances may sometimes force me to end the auction anytime between 4 and 22 days from the start.
- If two people bid at the same price, the person who bid first will have his slots filled first.
- Bids are considered invalid and will be ignored if they do not specify both a price and a max quantity, or if they could not possibly win any slots

If these rules are confusing, look at some of the past forum ad auctions to see how it's done.

I reserve the right to reject bids, even days after the bid is made.

You must pay for your slots within 24 hours of receiving the payment address. Otherwise your slots may be sold to someone else, and I might even give you a negative trust rating. I will send you the payment information via forum PM from this account ("theymos", user ID 35) after announcing the auction results in this thread. You might receive false payment information from scammers pretending to be me. They might even have somewhat similar usernames. Be careful.
209  Economy / Auctions / Re: Advertise on this forum - Round 206 on: April 21, 2017, 05:13:29 PM
Auction ended, final result:
Slots BTC/Slot Person
2 0.85 mynhpark
2 0.80 BITCOINIRA
5 0.80 exscudo
210  Other / Meta / Re: Timeout connection on: April 21, 2017, 04:45:15 PM
Changing the forum's IP address seems to have fixed it.

What was happening was that IP packets bound for the forum were being dropped or misrouted somewhere between certain ISPs/regions and the forum. It looks like about half of the world was affected. I only received one useful traceroute during the incident, and this showed that the packets were being dropped at or immediately after gtt.net, but I'd need more samples to draw any strong conclusions from that. (And it's too late to send me useful traceroutes now.)

I'll try to figure out more about what happened.
211  Other / Meta / Re: Timeout connection on: April 21, 2017, 03:56:19 PM
It's not a normal DDoS. It seems that certain places on Earth lost connectivity, while others work fine. So it must be a problem somewhere upstream of the forum's server.

If you still have problems, where are you and what ISP are you using? Post a traceroute if possible.
212  Other / Meta / Re: Get Donator status by donating 10 BTC on: April 20, 2017, 04:22:39 PM
Thanks to Claymore, the first Donator in quite some time.
213  Other / Meta / Re: Requesting threadposts to be restored on: April 17, 2017, 04:36:53 PM
I restored them to https://bitcointalk.org/index.php?topic=1874119.0 . I could still merge them into the main topic, but since there are so many, I thought this might make a mess.

These are all deleted posts, not just recently-deleted ones. (I don't have an easy way of distinguishing.)
214  Economy / Auctions / Advertise on this forum - Round 206 on: April 11, 2017, 05:56:34 PM
The forum sells ad space in the area beneath the first post of every topic page. This income is used primarily to cover hosting costs and to pay moderators for their work (there are many moderators, so each moderator gets only a small amount -- moderators should be seen as volunteers, not employees). Any leftover amount is typically either saved for future expenses or otherwise reinvested into the forum or the ecosystem.

Ads are allowed to contain any non-annoying HTML/CSS style. No images, JavaScript, or animation. Ads must appear 3 or fewer lines tall in my browser (Firefox, 900px wide). Ad text may not contain lies, misrepresentation, or inappropriate language. Ads may not link directly to any NSFW page. Ads may be rejected for other reasons, and I may remove ads even after they are accepted.

There are 10 total ad slots which are randomly rotated. So one ad slot has a one in ten chance of appearing. Nine of the slots are for sale here. Ads appear only on topic pages with more than one post, and only for people using the default theme.

Duration

- Your ads are guaranteed to be up for at least 7 days.
- I usually try to keep ads up for no more than 8 or 9 days.
- Sometimes ads might be up for longer, but hopefully no longer than 12 days. Even if past rounds sometimes lasted for long periods of time, you should not rely on this for your ads.

Stats

Exact historical impression counts per slot:
https://bitcointalk.org/adrotate.php?adstats

Info about the current ad slots:
https://bitcointalk.org/adrotate.php?adinfo

Ad blocking

Hero/Legendary members, Donators, VIPs, and moderators have the ability to disable ads. I don't expect many people to use this option. These people don't increase the impression stats for your ads.

I try to bypass Adblock Plus filters as much as possible, though this is not guaranteed. It is difficult or impossible for ABP filters to block the ad space itself without blocking posts. However, filters can match against the URLs in your links, your CSS classes and style attributes, and the HTML structure of your ads.

To prevent matches against URLs: I have some JavaScript which fixes links blocked by ABP. You must tell me if you want this for your ads. When someone with ABP and JavaScript enabled views your ads, your links are changed to a special randomized bitcointalk.org URL which redirects to your site when visited. People without ABP are unaffected, even if they don't have JavaScript enabled. The downsides are:
- ABP users will see the redirection link when they hover over the link, even if they disable ABP for the forum.
- Getting referral stats might become even more difficult.
- Some users might get a warning when redirecting from https to http.

To prevent matching on CSS classes/styles: Don't use inline CSS. I can give your ad a CSS class that is randomized on each pageload, but you must request this.

To prevent matching against your HTML structure: Use only one <a> and no other tags if possible. If your ads get blocked because of matching done on something inside of your ad, you are responsible for noticing this and giving me new ad HTML.

Designing ads

Make sure that your ads look good when you download and edit this test page:
https://bitcointalk.org/ad_test.html
Also read the comments in that file.

Images are not allowed no matter how they are created (CSS, SVG, or data URI). Occasionally I will make an exception for small logos and such, but you must get pre-approval from me first.

The maximum size of any one ad is 51200 bytes.

I will send you more detailed styling rules if you win slots in this auction (or upon request).

Auction rules

You must be at least a Jr Member to bid. If you are not a Jr Member and you really want to bid, you should PM me first. Tell me in the PM what you're going to advertise. You might be required to pay some amount in advance. Everyone else: Please quickly PM newbies who try to bid here to warn them against impersonation scammers.

If you have never purchased forum ad space before, and it is not blatantly obvious what you're going to advertise, say what you're going to advertise in your first bid, or tell me in a PM.

Post your bids in this thread. Prices must be stated in BTC per slot. You must state the maximum number of slots you want. When the auction ends, the highest bidders will have their slots filled until all nine slots are filled.

So if someone bids for 9 slots @ 5 BTC and this is the highest bid, then he'll get all 9 slots. If the two highest bids are 9 slots @ 4 BTC and 1 slot @ 5 BTC, then the first person will get 8 slots and the second person will get 1 slot.

The notation "2 @ 5" means 2 slots for 5 BTC each. Not 2 slots for 5 BTC total.

- When you post a bid, the bids in your previous posts are considered to be automatically canceled. You can put multiple bids in one post, however.
- All bid prices must be evenly divisible by 0.05.
- The bidding starts at 0.25.
- I will end the auction at an arbitrary time. Unless I say otherwise, I typically try to end auctions within a few days of 10 days from the time of this post, but unexpected circumstances may sometimes force me to end the auction anytime between 4 and 22 days from the start.
- If two people bid at the same price, the person who bid first will have his slots filled first.
- Bids are considered invalid and will be ignored if they do not specify both a price and a max quantity, or if they could not possibly win any slots

If these rules are confusing, look at some of the past forum ad auctions to see how it's done.

I reserve the right to reject bids, even days after the bid is made.

You must pay for your slots within 24 hours of receiving the payment address. Otherwise your slots may be sold to someone else, and I might even give you a negative trust rating. I will send you the payment information via forum PM from this account ("theymos", user ID 35) after announcing the auction results in this thread. You might receive false payment information from scammers pretending to be me. They might even have somewhat similar usernames. Be careful.
215  Economy / Auctions / Re: Advertise on this forum - Round 205 on: April 11, 2017, 05:54:22 PM
Auction ended, final result:
Slots BTC/Slot Person
6 1.50 exscudo
3 1.45 Baryom
216  Other / Meta / Re: Unicode 9.0 support for SMF 1.1.19? on: April 11, 2017, 09:26:04 AM
The forum software is not aware of unicode at all. It just spits out whatever bytes it's given. If some emoji characters don't display properly, it's a problem with your browser or with the character bytes entered by the poster.
217  Alternate cryptocurrencies / Altcoin Discussion / Idea: Scalable, flexible altcoin on: April 09, 2017, 11:24:56 PM
I was thinking about ways to solve some of Bitcoin's main problems -- verification is too centralized, miners are too centralized and too powerful, and safe scaling is difficult/limited --, and I came up with this idea for an altcoin which improves things in those areas. Although it does have several downsides, it does not take the usual altcoin route of "fixing" things by introducing tons of centralization and then pretending to be decentralized. I'm proposing it as an altcoin because Bitcoin could probably never be adjusted to work like this (though maybe it could be done as a sidechain). I think that it could work, and I'd love to see someone create it.

The altcoin has block headers similar to Bitcoin's, and similar mining (or better). Inside of the header is the root of a Merkelized search tree set (ie. it's a B-tree or whatever, but each tree node contains its children's hashes rather than pointers). With this sort of data structure, if you have a block's search-tree Merkle root, and you're in contact with a node which has the full tree for that block, then you can trustlessly get all branches from the tree matching a prefix. Inside of the header is also the root of a Bitcoin-style simple Merkle tree, called the existence tree.

When receiving a block, nodes verify the format and validity of the block header and sometimes (explained later) some facts about the two trees. But most of the data in block can be anything, and isn't verified.

Search tree keys are composed of a 4-byte application ID followed by application-specific data up to 40 bytes in length. (So search tree keys are 44 bytes long.) Interpretation of search tree data is up to applications.

Application 0 is the normal cryptocurrency application. Other cryptocurrencies or non-cryptocurrencies could use the same block chain, but I will now be describing application 0 only. A block's validity does not depend on any concept of validity of any data stored in the search tree, including application 0.

The miner of a block creates a coinbase transaction, and inserts into the search tree of the block he's generating the following key: 00000000 | first 8 bytes of hash(coinbase txid | prev-block txid) | coinbase txid. The second field is called the coin ID. He also inserts the coinbase txid into the existence tree.

When you want to send someone your coins, you create a Bitcoin-style transaction and get some miner to insert into a block the following key: 00000000 | first 8 bytes of hash(concatenate all parent coin IDs) | txid, and you also have to get the miner to insert the transaction's txid into the existence tree.

Upon receiving a transaction, you have to do the following:
 1. Verify that all ancestor transactions all the way back to one or more coinbase transactions form a valid transaction chain (ie. check tx format, signatures, etc.).
 2. Query the search tree of each block between and including the blocks which mined each ancestor transaction and its direct children, getting the txids of all transactions in those blocks with coin IDs matching the ancestor transaction. Download all of the transactions with those txids. Verify that none of them have already spent the coins being spent by the child transactions. If two conflicting transactions exist in a single block, the one listed first in the search tree is valid and the later ones are invalid/ignored. An entire application-0 search tree is not invalidated by the presence of invalid transactions.
 3. For each ancestor coinbase transaction, query its block for a matching coin ID, and check that all matching transactions are not excess coinbase transactions.
 4. For each block that you look at in the above two points, if you have not previously done so for that block, download the entire application-0 part of the search tree for that block and verify that it: 1) is well-formed, including being appropriately balanced; 2) it is below some size limit (which may safely be quite large); and 3) no single coin ID appears more than some arbitrary limit of times. If it fails any of these checks, then the application-0 search tree is invalid and completely ignored, but the block header is still accepted, and other applications could also be accepted. The data downloaded in this step can be discarded after checking, and you only need to do it up to one time for any given block.
 5. Check that the incoming transaction is eventually confirmed in both the search tree and existence tree of a block. If it's only confirmed in one tree, then it's not complete.
 
So you need to download a fair bit of data in order to receive a transaction:

 1. All ancestor transactions.
 2. All branches of the search tree associated with ancestor transactions.
 3. All transactions in those branches with the same coin ID as the ancestor transactions.
 4. Zero or one time per block, the full application-0 branch of the search tree.

#2 and #3 should be very small unless you are being targetted for a denial-of-service attack, in which case it should be limited to reasonable levels by the previously-mentioned hard limit on search-table entries per coin ID per block.

#4 should also be fairly small. A block's search tree will be roughly 2 * 44 * n bytes in size, where n is the number of transactions in that block. So at 10x Bitcoin's volume of about 2000 transactions per block, that's 1.76 MB/block, which sounds fine. At 1000 transactions per second, 10-minute blocks would have search trees of 52.8 MB, which is maybe still reasonable considering that normal users would only have to download some of them when verifying an incoming transaction, and unlike with Bitcoin full nodes, there is no particular time constraint on downloading the data.

#1 will probably be fairly large, but I'm not sure. (I was going to look through the Bitcoin block chain and collect average/median stats for this, but I haven't gotten around to it yet.)
 
It'll be most robust/reliable if each wallet saves data points 1 through 3 above when receiving a transaction, and then sends it to the next recipient when sending those coins. Then only the sender and recipient in a transaction have to deal with it. This could be done in many cases by associating transaction-sending with sending a file; if you want to pay someone in this altcoin, you'd always send them an email attachment or something. Both parties don't need to be online at the same time. But if this is still too cumbersome, the data could also be provided by third-party archival nodes instead, which would allow for Bitcoin-style "just send to an address" usage.

Fees would be handled by adding Script opcodes <key> OP_CHECKTREEKEYVERIFY and <hash> OP_CHECKEXISTENCETREEVERIFY, which return false unless the spending scriptSig is in a block with a search tree containing the prefix <key>, or if the spending scriptSig is in a block with an existence tree containing <hash>, respectively. So you'd add a fee to your transaction by creating a separate transaction with an output using the abvove opcodes, thereby paying the miner who mines the search/existence tree key of your original transaction. Miners would have to include in their blocks the paid-for transactions, the fee transactions paying for those transactions, and a transaction spending all fees. These opcodes could be combined with OP_CHECKSEQUENCEVERIFY or similar in order to time-out fees. This type of fee works cross-application, so you could pay a fee for some generic timestamping application via an application-0 fee payment. Since there is no first-class currency, it's also imaginable that you could pay for an application-0 transaction via a payment in a different application.

Note that changes to the currency are much easier under this system, while remaining substantially decentralized. Changes are always made by modifying the wallet/node software, with no miner interaction. When an old node receives a new-style transaction that it doesn't recognize, it can point to exactly where it sees the problem, and recommend possibly upgrading. For example, if a new opcode is added to Script, old nodes can give the error "Somewhere in the history of this incoming transaction, unknown opcode xyz was used. Maybe an upgrade is needed?". Or if any of the limits on search trees are increased, old nodes would say, "An ancestor transaction cannot be linked to a valid block in this incoming transaction. Some too-large search trees were skipped; maybe an upgrade is needed?" But if people don't want to upgrade, then they don't have to, in which case there will be a currency split and they would be unable to transact with people sometimes. Whenever there is an upgrade that old nodes would reject, the address version should change so that new nodes don't send transactions to old nodes that won't accept it.

The altcoin can easily support Bitcoin's full scripting system, and SegWit (with some modifications) could be added to it, so Lightning and other off-chain systems could be used with it. Such off-chain systems are useful even on a high-capacity block chain because they allow for microtransactions and instant confirmations.

Especially-powerful supernodes are needed in order to handle the following tasks:
 - Hard-reject blocks with missing data, or blocks that are too large.
 - Serve historical search trees and recent transactions / existence trees to other nodes.
 - (Optionally) Use bloom filters or similar in order to help nodes detect incoming transactions in new search trees
 - (Optionally) Store validity data for later checkpoints
 - (Optionally) Store all historical transaction data to help nodes with resyncing
 
The most important thing is that supernodes need to download the data associated with each hash in the existence tree in order to check that it exists. If any data is missing, then they must hard-reject the entire block (including header). If miners are able to include hashes with missing data into the existence tree, then the following attack is possible:

1. A miner send coins to a bank, but secretly also sends the same coins back to himself, keeping this second transaction a secret from everyone, but inserting the txid into the search tree and existence tree of one of his blocks, before the transaction to the bank.
2. The bank checks for double-spends using the search tree, but one of the transactions with the given coin ID can't be downloaded -- nobody seems to have a copy. Anyone can insert any hash they want into the search tree, so the incoming transaction can't be rejected based on this missing data. So the incoming transaction is accepted.
3. The miner now starts giving people the second conflicting transaction. The bank's version of the transaction is now considered invalid by everyone because it came second according to what anyone can see.

I don't think that there's any way to generate a fraud proof that a txid was missing in the past but is not missing now, so we have to fall back to the mining mechanism. Before building onto them, miners need to check that previous blocks actually have data associated with each hash in their existence trees. If a miner puts a hash into his existence tree without giving out the data for it, or if a miner builds off of such blocks, then these blocks need to be hard-rejected by the economy. Since checking for this requires downloading full blocks (which may be quite large), only supernodes can do this. The fact that only supernodes are doing this rather than the entire economy introduces some fragility, but I think that it's good enough.

When a block is invalid due to missing data, supernodes should at that point and in the future tell their connected normal nodes that that block hash is invalid, and also give them the Merkle branch to the missing txid in the existence tree so that the node can quickly check this with other supernodes. After a node has checked many supernodes for the missing data and failed to find it, he'll mark that block as invalid and reject blocks which build off of it. If the current highest-work chain is invalid due to this, then wallets should refuse to show any incoming transactions relying on blocks after the chain fork as confirmed, since the missing data could still make an appearance.

For similar reasons, the search tree also isn't allowed to be missing. Supernodes download the search tree and make sure that parts of it aren't missing, and similarly reject the block and alert normal nodes if it is.

The reason that there is a separate existence tree and search tree is that some applications on the search tree might not require the same existence guarantees, or might handle it differently.

Due to the above stuff related to proving existence, supernodes need to quickly download all transactions happening on the network, and they also need to quickly download the search tree of each new block. This will require a lot of bandwidth. To prevent only a very small handful of ultra-huge servers from being the only supernodes, a maximum size of block data is necessary. I envision supernodes being located mainly in data centers with "normal" bandwidth limits, not in homes, so the size limit will be set for that. For example, digialocean's $20/month plan has 3TB of monthly transfer, which would allow for 700 MB blocks if the supernode did nothing but download blocks all the time. Supernodes also need to serve data to regular nodes, so maybe a limit of 100 MB would be reasonable for now.

The max size would also be enforced by normal nodes. If a too-large block is produced, then supernodes can prove that it is invalid by giving out a part of the block which sums up to larger than the limit, and then linking all of that data to the block using the block's existence tree. Normal nodes would have to download data roughly equal to the single-block max size, which should be OK for a very occasional thing. Once a block is proven as being too large, it and all blocks building off of it are marked permanently invalid. Since it is rather expensive for a normal node to download full blocks, these fraud proofs might require a small one-time hashcash-style proof-of-work as an anti-DoS measure.

Although supernodes need to download all transactions, they can discard most of the data. They need to store:
 1. Full search trees for all historical blocks
 2. Recent (past month, maybe) transactions and existence trees in order to give to other nodes
 3. (Optionally) A list of valid transactions for later checkpoints. If this is stored, then the supernode also needs to actually verify all transactions, when usually it just needs to check that they exist.
 4. (Optionally) Supernodes can store all transaction data in order to help nodes resync, though this'll require a lot of storage.
 
Point #1 will be the main point of storage for most supernodes, though the altcoin would need to have a transaction volume 6x greater than Bitcoin's in order to equal Bitcoin archival nodes in storage requirements, so it's not too bad. Point #2 will be large but constant, and #3 will be insignificant. #4 will be massive (5.26TB per year with 100MB blocks), so only a few supernodes will do it, most likely. If senders and recipients save their transaction data, then archival supernodes are only needed in the rare case when someone has a private key but not the transactions which go with it, or when a new archival supernode is syncing.

As an optimization, the node/wallet software can periodically have a list of valid transactions added to it. Then when you send someone a payment, you only need to send them ancestor transactions since the last checkpoint. Not every valid transaction needs to be listed in the software -- only transactions which have unspent outputs. This list should be a snapshot of the state of the system several months in the past, it should only rarely be updated (maybe every year or so), and it should be independently verified by many people running supernodes; then the trust placed in the devs who add the list is fairly low. Unlike many altcoins, this is an optimization, not a critical component of the system's security.

Important note: In almost(?) all altcoins with a concept of supernodes, the supernodes end up being centralized controllers of the currency. I am NOT proposing that, and I am going to be very disappointed if someone is inspired to make an altcoin based on this post and then piles a bunch of trust on the supernodes. The supernodes in my design do not require trust, do not have special keys, do not vote, and anyone can run one and join the network as a first-class supernode. The only requirement is that regular nodes can communicate with at least one honest supernode. One of the main ideas behind my proposal here is to emphasize individual sovereignty, so under no circumstances should any decision-making be done by miner or supernode voting. The only acceptable way to make changes is to put a flag day in the node/wallet software and get people to upgrade.

Advantages compared to Bitcoin
 - Miners are less involved.
 - A lot more verification is done is a much more decentralized way.
 - Higher capacity is possible with reasonable safety.
 - Changes can be made in a way that is in most cases easier and safer, but without sacrificing decentralization.
 - You don't have to run a heavy full node in order to get halfway-decent security.
 - Other applications can be added to the same PoW chain in a way that is not generally disruptive to other applications.

Disadvantages
 - Normal users have to download/upload and store a fair amount of data in order to receive/send transactions.
 - Normal users verify most things, but not everything. Truly full verification happens only at supernodes, who will be fairly few in number. This is more fragile than Bitcoin.
 - You somehow need to get enough independent entities to run supernodes and serve normal nodes. Running one will be somewhat expensive (much more expensive for archival supernodes), and there's no reasonable way to have the protocol directly reward them. Maybe normal nodes will sometimes have to pay a fee in order to access the network.
 - Although someone could choose to avoid using checkpoints, in practice the checkpoints will probably become a very important optimization that people will rely on. This is a centralizing force, though if done properly it shouldn't be too bad.
 - Anonymity, another big issue, is not addressed at all here, and this idea is probably incompatible with the anonymity technology in Monero, Mimblewimble, or zcash.

(I am calling this general idea "arbchains" because miners are allowed to put arbitrary, mostly-unverified data in their blocks.)
218  Other / Meta / Re: Coin mention stats on: April 02, 2017, 09:56:44 PM
However, I have an inquiry: with every mention of Ethereum Classic, is there an additional count to Ethereum?

Yes.

I redid the top 15 from my rough result using more complex & accurate regular expressions:

Code:
Bitcoin: 126741   (\bbitcoins?(?!(?:\s|[-_#$%()*:@[^`{}~]){0,4}plus)\b|\bbtc\b)i
Ethereum: 22959   (\bethereum(?!(?:\s|[-_#$%()*:@[^`{}~]){0,4}classic)\b|\beth\b)i
Dash: 10466   (\bdash\b)i
Zcash: 5770   (\bzcash\b|\bzec\b)i
Monero: 5746   (\bmoneros?\b|\bxmr\b)i
Litecoin: 4358   (\blitecoins?\b|\bltc\b)i
Ark: 3872   (\bark\b)i
Waves: 3708   (\bwaves\b)i
Chronobank: 3517   (\b[0-9]+\W{0,4}TIME\b|(?i)\bchronobank\b)
Lisk: 2970   (\blisk\b|\blsk\b)i
ETC: 1592   (\b(?<!, )(?<!,)ETC(?!\.)\b|(?i)\bethereum\W{0,4}classic\b|\bethereum\b.*\bclassic\b|\bclassic\b.*\bethereum\b)
Faircoin: 818   (\bFAIR\b|(?i)\bfair[-]?coin[s2]?\b)
Synereo: 738   (\bAMP\b|(?i)\bsynereo\b)
Gamecredits: 722   (\b[0-9]+\W{0,4}GAME\b|(?i)\bgame\W{0,4}credits?\b)
Viacoin: 406   (\bVIA\b|(?i)\bviacoins?\b)

- ETC may be somewhat under-counted because any instance of "ETC" at the end of a sentence will not count, in order to avoid counting all-caps lists (eg. "SELLING BOOKS MOVIES ETC.").
- Dash may be a little over-counted because someone might use the English word dash without referring to the coin, and that'd count. There's no good way to avoid this.
- I figured out that Synereo was so massively over-counted previously because before posts are stored in the database, all instances of "&" are translated to "&amp;", which counted for them. In these more accurate results, I reversed such mangling and parsed bbcode before counting.
219  Other / Meta / Re: New Badges on: April 02, 2017, 09:41:32 PM
What were the possible titles?

Adherent, advocate, ambassador, apologist, CEO, super-CEO, champion, co-conspirator, defender, developer, "investor", facilitator, fanboy/fangirl, flunky, follower, grand poobah, president, proponent, supporter, expert, chief scientist, professional, amateur, and master.
220  Other / Meta / Re: New Badges on: April 02, 2017, 12:03:43 AM
Happy April Fools. Smiley

It was actually 100% random. Each user got between 1 and 4 coins, with fewer being more likely, and for each you would get a random cryptocurrency. I organized the cryptocurrencies into three tiers according to recognizability/popularity: tier 1 coins were more likely than tier 2 coins, which were more likely than tier 3. Then a random title was added to each coin name. There were a little less than 100 coins in total: I took the top 100 based on market cap and discarded a few that seemed to have never had any real interest.

But as I'd hoped, even though it was random, plenty of people just happened to have badges that were complete matches or mismatches. Smiley
Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 ... 344 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!