<unnamed>

Public Key

npub1dw9jxy0p6fyd6gxcxsqgp2uhslas47tam2y36kwjyzlryq3tuvtsvr3e7q

Profile Code

nprofile1qqsxhzerz8sayjxayrvrgqyq4wtc07c2l97a4zgat8fzp03jqg47x9cpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqw750lt

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:38:37 UTC

- reply

📅 Original date posted:2015-08-30
📝 Original message:I don't really see any problem with the paper:
All it states is that having the assumption that miners don't
centralize, transaction fees don't go to zero even without the
blocksize limit. I think we can accept this as a nice academic
research, and I believe that it's true.
Still, it doesn't have anything that is practical for me as an user of
the Bitcoin network (I use it for storing long-term purchase value, as
most of the people who I know): it doesn't help me if I still need to
pay transaction fees after the blocksize limit is gone. My (and other
users') main concern is about centralization, which has nothing to do
with transaction fees. I would be OK with $100 transaction fee as
well, as long as the network is fair and secure (which comes from
decentralization).

2023-06-07 15:19:46 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:Isn't a faster blockchain for transactions (maybe as a sidechain) solving
the problem? If there would be a safe way for 0-confirmation transactions,
the Bitcoin blockchain wouldn't even be needed.
On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn <mike at plan99.net> wrote:
> On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> Right, this works in the Bitcoin network today absent any collusion by
>> the miners. You give one miner a transaction and you give every other
>> node you can reach another transaction.
>>
>
> Yes, but that can be fixed with double spend alerts.
>
>
>> Someone you ask to not double spend is an entirely separate matter.
>> They aren't self-selecting: you select who you trust to not make
>> double spends and there is no need for this trust to be globally
>> consistent.
>>
>
> No? It's not just your decision that matters, the receiver also has to
> trust them. They're like a dispute mediator in this regard. You can pick
> whoever you want, but that doesn't matter if the receiver doesn't recognise
> them or trust them. You have to find an overlap to make an instant trade.
>
> In practice if people have to think about this, evaluate brands etc then
> you'd get a very small number of parties because the value of global
> agreement is so high. Then it becomes hard to remove ones that have a lot
> of momentum.
>
> The censorship resistance of the block chain doesn't matter if your double
> spending partners refuse to help you spend your money (because they're
> being coerced). The censorship can just happen at a different place.
>
>
>> To stop GHash.io we would have to take away their hardware or change the
>> Bitcoin
>> protocol to make their hardware useless
>>
>
> ..... or, have a majority decide to zero out their coinbase rewards for
> blocks that double spent against dice sites. That wouldn't undo the double
> spend, but you can't do that with the multisig scheme either. All you can
> do is punish the corrupted party post-hoc, either by not using them again,
> or by "unpaying" them for the service they did not provide.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/381deca8/attachment.html>