Yes, I understand. I think the source of this money comes from the device Satoshi Nakamoto?
No, there is no "device Satoshi Nakamoto". The coins are created on a protocol level as a reward for the miners securing the chain. These "bitcoins" are really just mathematical tokens which are very carefully controlled by the network protocol to prevent counterfeiting, theft, etc.
You can find more on StackExchange. as far as i know he never explained why
There doesn't need to be an explanation for something that may very well be an arbitrary number as long as the limit remains fixated. |
|
|
|
Ignore the advice above. As some of us have said numerous times, do not use third party wallets. Doing something like that has a lot of in common to the traditional system and keeping money in a bank. Those providers (some or most of them) do not give you any private keys. Note: Bitcoins on addresses to which you do not own the private keys to are not your Bitcoin. Generally it is best to keep the money in your own pocket.
That being said, why would proceed with a mobile wallet at first (unless you have some plan to spend it right now)? I'd recommend (at least) a SPV desktop wallet like Electrum. Just try Coinbase or Blockchain if you want.
Bither is much better than both of these suggestion. |
|
|
|
|
Sometimes it's a tough call to make when it comes to impersonation. Even though the username does look very similar in this case, it could be very well a genuine member that chose this name. It may be worth keeping an eye on them.
|
|
|
|
I think Natty and I are going to open the first 2 for Auction with the first one #00 being something really special which we are still finalizing.
Any ETA for the auction? As for a price point we have yet to finalize that but just the spot price of silver will be $100 as a base so we expect somewhere about 20% +/- or so above Spot again this is not finalized and will also depend on what the first (2) go for in auction
I'm pretty sure that if you go for $100 + 20% that these will sell very quickly, even though the design has nothing to do with Bitcoin (from what I can gather). How are you guys handling the funding for them?
Seems I have missed something. These are going to be funded? |
|
|
|
Is this Franky guy just a total troll? I'm feeling like I've been trolled. Can't believe I took like 45 minutes to write that post, only to have him ignore every single point, yet again. And here he is, foaming at the mouth, babbling incoherently about "core fanboys" and "monero is the future."
Several people have given them more than plenty of chances here, but they usually just seem to write up huge posts of flawed nonsense. They're very persistent with their flawed understanding of the underlying protocol, in addition to trolling members with high knowledge (e.g. DannyHamilton). Basically if you do not want what they want, you are one of the following or more (according to them: 1) A Core fanboy living in a delusion. 2) Blockstream shill. 3) Monero shill. all because they dont want increased capacity, and are telling people how scary controversial splits are because they themselves fear consensual capacity increases as it will de-incentivise the (heavily invested corporate) need to go offchain
We've already discussed the on-chain capabilities of Bitcoin, which currently are far from what certain groups are advertising for. |
|
|
|
If you restrict transactions to 1mb, then you can scale linearly from the current worst case.
What do you mean by "restrict transactions to 1 MB"? Restrict the maximum size of an individual transaction to 1 MB? Bitcoin unlimited is running a testnet with 10mb blocks and they aren't even close to straining decent desktop hardware.
I highly suspected that they are testing normal 10 MB blocks, which is obviously the wrong way to test stuff. Otherwise, that statement wouldn't hold ground. At 10 MB, with quadratic validation time, you could reproduce a block that requires a ridiculous amount of time to process. Bandwidth usage can be high, but 20mbit/second is pretty easy to come by. If you have less, you can serve fewer nodes but still provide more to the network than you consume.
The problem isn't the speed, the problem is the amount that you spend. Even at 1mbit/s, you can have 40-80 connections (again, source: my node). However, do you really think that you wouldn't be throttled down very soon considering that they'd probably label this as "not fair use"? |
|
|
|
-snip-
Tl;dr; I would sacrifice decentralization for money.  lots of people have done benchmarks and deemed 4mb raspberry pi safe.
but here is lauda being ignorant and now avoiding other bench tests just to provoke an argument that i didnt do as he said.
No. You're the one that mentioned validation time on a Pi in this thread. I asked YOU to run YOUR own benchmarks, not pull stuff from the internet to back it up. ill repeat what he and his immature friends say when i ask them to research something
"dont tell me what to do unless your paying me"
I'm not going to waste my time researching for someone who thinks that libsecp256k1 mitigates the quadratic validation time problem. and even if i did spoonfeed him. i predict he would just say i made it up (yes he is that predictable)
Of course you'd likely make it up since you can't even properly document your testing methodology. anyway using todays settings 2mb spam is 4 seconds.. not a 11 minute bottleneck
You clearly have no idea what you're talking about. |
|
|
|
Does anyone know why current blocks take so much longer to download in Bitcoin Core than old blocks? As far I as know the increased difficulty is only related to mining and has nothing to with checking downloaded blocks.
Example: When I start a fresh installation of Bitcoin Core, it starts downloading the blockchain. It quickly goes through the first years with small blocks, then after that it's downloading with more than 2 MB/s continuously. That means at least 2 blocks per second (say 90 seconds to download 1 day's worth of blocks). But when it gets closer to the current date, it slows down.
I'm not sure how you don't know the obvious answer to that question: Because the blocks are larger. Just because the block size limit has been at 1 MB for years, that does not mean that the blocks were actually 1 MB in size. Blocks prior to 2015 and 2016 were usually quite smaller. Note: Downloading these blocks at 2 MB/s isn't the bottleneck, but validating them is. You can speed this up if you add a high "dbcache" setting (e.g. 4-8 GB). Now when I start Bitcoin Core, it downloads fast for a bit, then stops, continues a bit later again, and then downloading stops entirely for a long time. CPU load is low, hard drive I can't hear (and I have no indicator LED). My question is: why is it so slow? Why can't it continue to download 2 MB/s so I can update 3 days in 5 minutes?
It shouldn't stop if it isn't doing anything. Relying on HDD noise is a bad way of testing whether it's actually doing something. If the CPU load is low, then the bottleneck is the IOPS of the HDD. As another test, on my old Atom laptop, it updates 3 weeks blockchain in 2 calendar days. To come back to the statement I quoted: if blocks would be 20 times larger, and I extrapolate this, my old Atom couldn't keep up anymore. And if this gets worse in the future, it could become a limitation for faster hardware too.
Again: Validation time. You could copy over the whole blockchain and do a reindex to check. In other words, reindex builds the blockchain index and chain state from scratch (no downloading). You're going to notice that it takes a lot of time, especially on weak hardware such as yours.
Hint: Something like this should probably be discussed in a separate thread. |
|
|
|
Yeah, it is subjective. My desktop could easily handle 20 mb blocks, and it isn't anywhere near top of the line.
No, I'm fairly certain that you've pulled that out of thin air. Exactly where, when and how did you benchmark validation time for a 20 MB block? Quadratic scaling induces problems with malicious 2 MB blocks, now imagine the implications on 10x of that. Sure, in 5 years I'd need more disk space, but I could also buy enough disk for 20 years at that rate for less than $600. In 5 years when I actually need it, that storage will likely be even cheaper. The CPU, RAM, and network connectivity I have today can already handle it.
You are forgetting several things in your point of view: 1) Syncing from scratch; 2) Bandwidth. Sure, you could argue that you'd need only download 20 MB worth of data on average every 10 minutes. However, this does not apply for full nodes, but full clients. A node, doing an average of 1 mbit/s at the current block size of 1 MB, will spend around 300 GB of data in 30 days (source: My own node). |
|
|
|
i even bothered to check a few websites to see several benchmarks to to make sure its not a fluke.. but heres one.. which also covers the bits about 8mb too https://rusty.ozlabs.org/?p=515Initially I've asked you to provide your own benchmarks on a raspberry PI. These are not your results. seems rusty can get better than 2 seconds, but im guessing from reading it he was using a i3 laptop.
there were other sites and benchmarks saying increasing the dbcache also improved things too, but yea that digresses off the point
Increasing the dbcache does speed up overall time, but that's not what we're trying to accomplish. I'm talking about default settings, and raspberry PI (since you've mentioned it). basically 2mb spam tx is not a bottleneck of doom 11minute scare story.. but a 4 second validation time
That's not correct. by the way google and a thing called research is your friend.
You've made claims, ergo you should back them up with sources. I'm not going to do the homework for you. |
|
|
|
lol so transactions are no longer median 226 bytes? or as i said average ~450bytes
Median is still 226 bytes, as shown on this website. remember the sigops issue is not a problem for median/average transactions.(you know transactions that dont have much signatures) and only a problem for bloated transactions (you know such as what will be noticeable when lightning hubs start dealing with many signatures) where the average and even your magical median increase.
No, neither one holds true. Nobody ever claimed that the quadratic scaling is problematic with normal transactions. It is just an attack vector that could be abused by a malicious miner. "Could be" doesn't mean that it "will be" though. block: 364292 validated in 2 seconds.. as oppose to pre libsecp256k1 which took far far far longer. Where is the source of this result ("2 seconds")? other standard blocks 0-400,000 validated in under 6 hours (18 blocks per second)
as oppose to pre libsecp256k1 which took far far far longer.
That doesn't matter. As previously stated, while libsecp256k1 improves validation time significantly it does not mitigate the attack vector at 2 MB (Gavin even confirmed this somewhere). |
|
|
|
"A" and "B" please.  Added both your tickets. 6 spots down, another 26 to go before we spin the wheel. |
|
|
|
sorry to tell you this but 2mb is actually healthy right now..
libsecp256k1 alone (released ages ago) has actually made enough efficiency boost to make 2mb blocks healthily able to run on a raspberry pi.
No, that's not right (if it was right, there would be no need for sigops limitations in Bitcoin Classic). I've addressed this issue about 6 months ago already: in order to sign or verify the tx, each input has to construct a special version of the tx and hash it. so if there are n inputs there are nxn hashes to be done. hence quadratic scaling.
the TLDR I believe is: ecdsa operations are the most computationally expensive part of verifying transactions, for normal, small size transactions, but they scale linearly with the size (number of inputs).whereas if a transaction in current bitcoin has tons of inputs, the bottleneck moves over to the hashing/preparing data to to be signed, because that time depends on the *square* of the number of inputs.
so usually it's ultra small, but it blows up for large N inputs.
Why doesn't libsecp256k1 have an effect on this? because libsecp256k1 is an ECC library so it's only the "ecdsa" part in the above.
I don't know why you keep persisting that it doesn't. You should run a benchmark on that raspberry PI and validate only the block full of spam that was mined by F2Pool back in 2015 or 2014 (it was mentioned in the conference). |
|
|
|
ridiculous blocksizes??
sorry but segwit is 4mb.. i proven that in a different topic and even supplied you a link.
so how is 2mb ridiculous??
Yes, I'm talking about ridiculous block sizes. Examples of those being suggested by irrational people: 8 MB, 20 MB (remember 2015 20 MB now or doomsday?), unlimited. 2 MB should be fine after validation time is linear and not quadratic. i actually agree with lauda's sentiment..
Additionally, I strongly believe that any controversial fork is an altcoin in a sense where a very small minority split away from the majority. We define pretty much any coin that does this as an altcoin; the primary difference is that they: 1) Change some specifications; 2) Don't retain the current blockchain information but rather start 'fresh'. well there already has been logical bips submitted, and the decision against implementing it was not vetoed out due to code, or logic or real reason. but due to false doomsdays and fake stats.. mainly illogical scare stories
You can't get something merged into Core without consensus. What you could do is: Write a BIP -> provide the code for it -> if it gets rejected, then provide your own implementation for it. I'm also not aware of any "false doomsdays or fake stats" that were used as arguments against any of those BIPs. |
|
|
|
Why does everyone need to run a full node?
No, not "everyone" has to run one. We're already pass that point IMO. However, you should be able to run a node without it costing you a lot of money (this is subjective I know) if you want any kind of decentralization. See section 8 of the bitcoin white paper. Even Satoshi viewed full node operation as a business activity. If you didn't sign up for Satoshi's vision, what exactly did you sign up for?
Just because Satoshi had a view regarding something, that doesn't mean that they were right. I disagree with 'running a full node to being a business activity'. It's not like the node count isn't slowly going down due to the ever increasing resource cost required to run one. Remember, BTC is now being ran by these types:
-snip-
So we should believe in Ver's words, the same person that vouched for Mt.Gox solvency? |
|
|
|
|
This topic has been moved to Trashcan.
Reason: Insubstantial introductory thread.
|
|
|
|
Only 30%  This is very disturbing. Must collect more for a 51% attack on Genesis coin network!!!! Mantis definitely does not have enough Genesis, time to buy up more! oh nos.... we will rebrand as Genesis Classic.  For the sake of completion of your chart I have ...
AC 026
PS 028
PC 036
Thanks. I've updated the manifest, but won't post another update until we acquire more information in order to prevent flood. |
|
|
|
|
Show Posts
