 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
I use Web wallets. I know many people think that it is insane to use them, but I think since you can't be 100% safe using any wallet, why not use a convenient one then.
Coinkite is my favorite. If I'm making a terrible mistake please tell me.
Why not use an offline SPV based wallet, instead of a web based one. You should, at the very least, have a paper wallet back-up of your private keys. |
|
|
|
|
Thanks for the clarification Danny, really appreciate your time and contribution. Great explanation
|
|
|
|
|
Help me get this straight... A single Public Key can have multiple private keys?
I mean, can I use Vanitygen and input an exact address, in hopes of generating the keypair?
thanks
|
|
|
|
|
What if someone were to generate keypairs randomly while simultaneously scanning the blockchain for any addresses generated that have previous inputs? How unlikely is it to generate a 'used' address?
|
|
|
|
|
He'll eventually have to do something with his coins, unless he wants us only to have 20million coins instead of 21.
How do you guys believe he will go about getting them back into the bitcoin economy? Multiple wallets or not he mined a good sum of blocks, and the coins still remain at the coinbase address.
|
|
|
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.htmlLast we heard from Satoshi was on August 15th of this year in the midst of Round 1 of Block-size debate. "I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork. The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the "original vision" they claim to honour. They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism. If two developers can fork Bitcoin and succeed in redefining what "Bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project. Bitcoin was meant to be both technically and socially robust. This present situation has been very disappointing to watch unfold. Satoshi Nakamoto" Email originated from vistomail servers.
|
|
|
|
|
We don't need change we're not ready for. The 1MB Block size symbolizes not only a technological limitation on the network, but a limitation of the capability of the community.
We don't have a proper solution to the Block size increase yet. We also need to address node incentives (if we're to implement hard forking change). Satoshi said he believes we need a way to incentivize the propagation of fresh transactions to the network.
Has anyone read the white paper on Bitcoin and red Balloons?
Was
|
|
|
|
|
We knew this day would come. Round Two will be soon.... perhaps people will be more ambitious in implementing a solution this time around.
|
|
|
|
|
You're gonna have to design it (HTML, CSS, and if you want dynamic elements that don't require refreshing the page, Java.) Then you'll need to have an organized back end db and likely use PHP for that, in addition to JSON-RPC calls to Local Bitcoind.
Let me know how it goes.
|
|
|
|
FWIW isn't Lightning Network a band-aid solution?
No, far from it. I suggest you seriously look into it. Right, I've looked into it. It seems like instead of taking the necessary steps to outfit Bitcoin, nodes and miners with the ability to handle VISAs volume of transactions, we should just do transactions off-chain and trust Hubs? I don't believe this was a part of the creator's vision for bitcoin. Transactions large and small are supposed to be affordable to do on the blockchain, and if Lightning is adopted it would only be because of altruism or it is too expensive for people to use the blockchain. Is this what we want? This all creates complications that people are fearful of. Like keeping the internet strictly HTML forever in 2000 because most people only had 56k? |
|
|
|
Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold. How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand? However I believe this to be nearing its maximum efficiency and closing in with Moore's Law. Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs. And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law? Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand. You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling. In addition, the "larger" Bitcoin becomes, the more incentive exists for any company that deals with money (I would assume most do) to invest in it remaining capable of handling transaction volume. This means dedicated internet connections for nodes and things of that nature. A business that deals with credit card processors, for example, save 3% a year, which can be put back into the business and increase the next years profits. But I also believe Satoshi was correct in saying "I suspect we need a better incentive for users to run nodes instead of relying solely on altruism." Last month. |
|
|
|
|
FWIW isn't Lightning Network a band-aid solution?
|
|
|
|
|
I like great ideas, but great ideas do not fair well on the forums.
Dynamic Block size with min. change to 2MB no doubt.
Whether or not the change is proportionate to difficulty of mining is not really what I would call relevant. The main concern is latency when blocks begin to get into the double digits but people overlook the added incentive of increased transaction volumes = increased incentive.
We could keep 1MB until it starts slowing down the network and then go to a Fibonacci Sequence that increases dynamically based upon whether the block size is deemed too small by Core. Say if Mempools start crashing Nodes etc...
1MB,2MB,3MB, 5MB,8MB, 13MB, 21MB etc
I really appreciate your time and contribution but I believe all the Core developers have already been bought out by Blockstream so they can be the First Lightning Network hub and take fees from miners and keep 1MB forever because they want to capitalize on the inability of the community to reach consensus without arguing.
People like you are who keep bitcoin going. Thank you. Remember, We Are Satoshi.
was
|
|
|
|
Perhaps we're doomed to be taken advantage of for the rest of eternity by centralized financial institutions. At least they can handle transactions.  In addition, blockstream's only interest in small blocks is so they can implement lightning network as one of the first and most trusted hubs. Without small blocks, there is no need for lightning network. In the end, though, we need a decentralized way to deal with issues regarding a decentralized network. |
|
|
|
So, all of these people were in on it and now 3 people have to change their identities and move far away to perpetuate the hoax.
Or...one guy shot 3 people, one of which survived, then shot himself.
Exactly. Conspiracy theorists will make a conspiracy out of absolutely anything at all. Please someone tell me what would be the benefit of faking this incident and for what motives? This shooting looks obviously staged, so much so, I thought it was a joke. However, there have been many shooting "drills" in the recent month, and it just so happens these reporters, and news company in particular, reported on one at a school about a week ago. I Forget the exact link on this webpage but they had dates for drills scheduled where supposed "fatal shootings' were reported on my mainstream media... I believe the Church Shooting was one fletc.govEDIT: Here ya go :https://www.fletc.gov/training-calendar it was the charleston shooting that the dates matched up to the "event" |
|
|
|
You need some sort of limit at some point because you need restricted space so fee market can develop.
A fee market will be needed at some point, even tho its not necessary now.
Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.
edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.
(also unlimited block size might lead to huge blocks and problems for network)
Tx fees will be enough to properly incentivize the miners to secure the network in 2140. Rest assured. Perhaps instead of discarding 21 Million limit, you could add a 9th decimal place? 1/10 of a satoshi? A dime? was |
|
|
|
I'd vote, but I don't see an option for "none of the above".
Well, I figured that was called "reply". |
|
|
|
|
Option 4 Would be my choice, if Network grew to outpace capabilities of Machine and bandwidth, and began to sacrifice centralization, this would create a fee market which further incentivizes advancement of technological capability. (while still allowing transactions to be processed)
Poll on
was
|
|
|
|
|
This is not what we need, we need Bitcoin Core to publish Satoshi 12.0 with dynamic block size and thats it. this XT vs Core will kill bitcoin. Two bitcoins? Two blockchains?
This all sounds very dangerous and juvenile.
|
|
|
|
Why not implement a database of balances, and snacks deposits and withdrawals for buyers and sellers instead?
Wouldn't be publicly audit-able |
|
|
|
|
