Topic: Bitcoin Scaling Solution Without Lightning Network... - page 4. (Read 1727 times)

I have discussed it a couple of times before and you are welcome to check this post for instance. AFAICT what you are asking for is totally possible and it leads to a new generation of full nodes which are light enough to retire current spv nodes.

By the way, hierarchical or not, sharding as an on-chain scaling solution is not something we could ever ignore.

   We just want to give people a better alternative to using the banking system. If we are just going to try and herd people into using lightning network, is that system really any better? If BTC ever gets wide adoption, it won't even be affordable for many to open a LN channel for themselves. They will just have to rely on some gateway service to open channels, and your "share" of the channel will just be kept track of by the gateway service. The casual user will just need to rely on some third party, and hope that they are not "hacked."
    To get back somewhat on topic a little. I think if BTC can implement some kind of system where a node can validate each and every transaction without having to initially devote enough hard disk space, that would be great. My understanding of pruning is that you initially have to devote the required hard disk space before you can prune. I'm not certain the OPs proposal is the best way to go about this with the sharding.

@bones26
Perhaps, but since @franky1 regularly tell us how Bitcoin is dying since there are "fewer transactions". The case you mention is not supposed to happen so, or just randomly (during the Christmas month with all people buying the gifts lol). There is no problem anymore with the fees or congestion by following him

  No, we are not forced to use Segwit. However, if someone chooses not to use Segwit, you are penalized by paying higher fees. This may only amount to pennies at the moment, but it can add up. If BTC starts to get used even more, many casual users will then be compelled to use LN, to avoid prohibitive fees.

@franky1
This is what we call being proactive and anticipation. The example you give about the SegWit roadmap from 2014 is one example. Are we forced to use SegWit? As DoomAD says, they cannot integrate everyone's wishes, but they anticipate to make Bitcoin usable with various convenients solutions. It's like complaining because someone is working to improve Bitcoin and talk about consensus. A consensus from the mass could turn in a 10 years old kid decision.

Multiple layer of confusions over there:

1- Spamming is bad for bitcoin but not a serious threat right now, besides transaction malleability which is was a flaw and essentially have  improved after SW, other spamming practices come with a cost. Making bitcoin more resistant to spam is good but not an urgent agenda neither a relevant issue to on-chain scaling.

2- It isn't reasonable to consider it kinda "punishing others" when you make frequent txs. You pay fees, you utilize the service, that simple.

3- And it would be insane to encourage people to keep UTXO more occupied! Actually I'm working on a totally opposite direction. By any measure we need to keep UTXO as light as possible, UTXO is the problem and not the chain, chain always could be pruned, UTXO couldn't. I think people should pay even more when their balance is kept for a longer time than others. It occupies space!

Let's discuss an alternative approach:

Suppose as a decentralization measure we incentivize wallets to run a full node and participate actively in consensus by a replace-fee-by-work schema. In this schema wallets are free to do some work (solving an ASIC resistant hash function) and include a nonce plus the hash of the most recent block they are ready to commit to. By confirming such transactions, miners could enjoy a tiny discount for the difficulty they need to approve their block and ready to be more generous with the fee they expect. Let's call it Direct Commitment By Transactions.

For such a schema to work we need to give more weight to commitments to newer blocks and stop giving such a credit to transactions when they are committing to blocks older than 100 or so. More interestingly we could discourage hoarding and occupying the UTXO too long,  by means of another complementary technique which is even more disruptive and deserves to be called Indirect Commitment By Transactions.

Traditionally, in bitcoin and its clones, ordinary transactions use a txid:[#ouput] format as their inputs. Although this approach has some benefits and provides a level of convenience  for users it has drawbacks too. For instance, reply attack in forks wouldn't be possible if wallets was committing to the branch they are making the transaction for.
In Direct method above we have established such a possibility, now suppose we go even further and let transactions to refer to outputs by their relative position in the blockchain and give another bonus (difficulty discount) to miners for including transactions that spend younger outputs from the correct chain as by this reference they are indirectly committing to the right chain, helping security.

maybe instead of defending them. realise they release code BEFORE community input/conversation.

EG
they had segwit roadmap plan from 2014. before community input
they had code before community got to download.
the comunity had a november 2016-spring 2017 decision and devs lost.
but that was not acceptable to devs. hense the mandatory august 2017.. (no conspiracy. check it all out (i wont use the R word.))

it was not a concept of taking in random community idea's and going with the best one. it was them build thier road map and sway the community to adopt.
you might want to check it all out (i wont use the R word.)

as for me insulting . thats the bear biting the poke. not me poking the bear.
same went for your social drama involvements
if you word count actual insults i give against. say insults you give. you will be surprised by the result

all i said to you before as REPLIES was to re***rch(i know you dont like the word) .. check it out.
you were the one that resorted to flame wars.

anyways. things wont change no matter how much i kiss ass of a dev. the only main issue is that devs should change to be a more OPEN community. and not REKT things that are not their plan..

sorry but letting them lead and control, and require kissing the royal ring is not what decentralisation is about

It might be worth considering that if all you ever do is verbally abuse them, they might not be very receptive to what you're saying.  It's not just about having a good idea, it's about how you present it and (particularly in your case) how you conduct yourself while doing so.  

I could have the best idea in the world, but if I spent the entire time slagging off the people who I'm trying to convince to adopt it, it stands to reason that's not going to go the way I'd like it to.

It's overly simplistic to talk about whether developers "should" or "shouldn't" listen to the community.  It's not that black and white.  Each and every single idea has to be treated on a case-by-case basis.  What this is really about is that each developer and dev team is naturally going to produce the code which they believe is most likely to lead to Bitcoin's overall long-term success.  It's not practical for them to implement every random idea people throw out there.  Many of the ideas people suggest (or demand) are not viable.  So they have to be selective and focus on the few decent ideas.  But how can they know your idea is decent if they can't even hear it over all the conspiracy theory babble and outright FUD you constantly spout?  If you want the community to take your idea on board, the onus is on you to present a reasonable argument to support your case and convince them that your idea is actually worth implementing.  Then, with community support, developers are more likely to listen.  If they are then convinced your idea has merit, they are more likely to implement it.  Or, as always, feel free to skip that process and either pay someone to code it, or code it yourself and see how the community reacts then.

But don't just demand shit like an entitled child and then insult the developers when they inevitably ignore you.  When has that attitude ever worked for you in the real world?  That's not how you get what you want.  Try being an adult about this.  Yes, I think you have a good idea, but you really need to work on your people skills.  All you've earned for your efforts so far is negative feedback from a developer.  If you had been more reasonable from the offset, things could have been very different.  Seriously re-think your posting habits and mannerisms in general.  You only have yourself to blame if people aren't taking you seriously.

All that put aside, I will start a topic about fee priority for you if you don't think you can conduct yourself appropriately.  But I think it would be healthy for you to start one, while taking on board what I've said above and really watching your tone.  Maybe even open with an apology for your behaviour to date.  It's not too late to change.

i raise many points many times. the thing is, you meander in when the 4 letter word that a center of an apple is called is mentioned. thus you only see that point.

its like if i mentioned "you never see a blue lambo on the road". suddenly you start looking out for it and start only noticing blue lambo's and reacting/get emotional to it everytime you see one. not noticing the lack of observation and lack of emotion of other vehicles

that said the 4 letter word you defend is actually the ones that do type the code and do release the code because all others have been pushed off the network or pushed out the relay layer into the downstream "compatibility" layer of the network topology.

so just running nodes wont change the rules. just mining hashpower wont change the rules. we need actual devs to code rules. which goes against your perception of what devs should be doing. which is what we disagree with.
devs should be listening to the community.

again whats the point of me posting something about a rule change like the second part of your reply. if your side feels that devs should not listen to the community and just do whatever they please.
do you atleast see my point that the network should not have a power house that ignores the community, simply because it doesnt fit "their" roadmap

but seeing as your on their side how about just forwarding the second part of your post to them. you can even say its your idea if it helps. i have thrown many idea's out and let anyone take them and use it as their own idea. like i said a few times im not writing code as a authoritarian demanding people follow me. i never have. i just inform people what could/should be done and hope it wakes people up to see there are other options than just the 4 letter word's roadmap, and that we should not just blindly sheep follow a roadmap as if its the only way

If you just stuck to raising points like this, rather than simply attacking everything that others are trying to build, I wouldn't have to spend so much time arguing with you.  This is one of those rare cases where we actually agree on something.  My only minor critique with this post is that you did a much better job of explaining this concept here:


I've yet to hear any technical arguments from anyone as to why this isn't a good idea and something we should be seriously looking at.  In fact, I'd even suggest you start a new topic in Development & Technical Discussion just for this point alone.

finally doomad sees the light about "compatibility not = full node".. and how "compatible" is not good for the network..
one merit earned... may he accept the merit and drop that social drama debate now he seen the light.

onto the topic
the hard fork of removing full nodes that can only accept 1mb blocks has been done already, in mid 2017. reference the "compatible" nodes still on the network are not full nodes no more.

all is required is to remove the "witness scale factor" and the full 4mb can be utilised by legacy transactions AND segwit transactions.
this too can have positives by removing alot of wishy washy lines of code too and bring things back inline with a code base that resembled pre segwit block structuring to rsemble a single block structure where everything is together that doesnt need to be stripped/"compatible".
yes the "compatible" nodes would stall out and not add blocks to their hard drive. but these nodes are not full nodes anyway so people using them might aswell just use litewallets and bloom filter transaction information they NEED for personal use.

we will then have the network able to actually handle more tx/s at a 4x level rather than a 1.3-2.5x level(which current segwit blockstructure LIMITS (yep even with 4mb suggested weight. actual calculations limit it to 2.5x compared to legacy 1mb))

...
as for how to scale onchain.
please do not throw out "LN is the solution" or "servers will be needed" or "you cant buy coffee"
1. instead of needing LN for coffee by channelling to starbucks. just onchain use a tx to btc buy a $40 starbucks giftcard once a fortnight.

after all from a non technical real life utility perception of average joe. if your LN locking funds with starbucks for a fortnight anyway. its the same 'feel' as just pre-buying a fortnights worth of coffee via a giftcard.
(it also solves the routing, multiple channel requirement for good connection, spendability, also the other problems LN has)

2. onchain scaling is not about just raising the blocksize. its also about reducing the sigops limit so that someone cant bloat/maliciously fill a block with just 5 transactions to use up the limits. EG blocksigops=80k and txsigops=16k meaning 5 tx's can fill a block should they wish. this is by far a bad thing to let continue to be allowed as a network rule.*

3. point 2 had been allowed to let exchanges batch transactions into single transactions of more in/outputs so that exchanges could get cheaper fee's. yet if an exchange is being allowed to bloat a block alone. then that exchange should be paying more for that privelige, not less.
(this stubbornly opens up the debate of should bitcoins blockchain be only used by reserve hoarders of multiple users in permissioned services(exchanges/ln factories).. or should the network be allowing individuals wanting permissionless transacting).. in my view permissioned services should be charged more than an individual

4. and as we move away from centralised exchanges that hoard coins we will have less need for xchanges to batch such huge transactions and so there will be less need of such bloated transactions

5. scaling onchain is not just about raising the blocksize. its about making it more expensive for users who transact more often than those who transact less frequently.
EG imagine a person spend funds to himself every block. and was doing it via 2000 separate transactions a block (spam attack)
he is punishing EVERYONE else. as others that only spends once a month are finding that the fee is higher, even though they have not done nothing wrong.
the blocks are still only collating the same 2000tx average. so from a technical prospective are not causing any more 'processing cost' to mining pool nodes tx's into block collation mechanism. (they still only collate ~2000tx so no cost difference)
so why is the whole network being punished. due to one persons spam.

the person spending every block should pay more for spending funds that have less confirms than others. in short the more confirms your UTXO has the cheaper the transactions get. that way spammers are punished more.
this can go a stage further that the child fee also increases not just on how young the parent is but also the grandparent

in short bring back a fee priority mechanism. but one that concentrates on age of utxo rather than value of utxo(which old one was)

Ok, but big blocks are inherently centralizing the bigger they go, are they not? Sharding would only prolong the issue on the network, any blockchain network, of scaling in.


For Bitcoin? I believe it would be better proposed in a network that has big blocks, and does not have firm restrictions on hard forks. Bitcoin Cash ABC.

The main problem is that most of these scaling solutions that are being proposed will first require a hardfork. This means we'll have the drama of 2 competing bitcoins trying to claim that they are the real one (see the BCash ABC vs BCash SV ongoing war right now). This will not end well. Without consensus we will just end up with 2 bitcoins which are in sum of lesser value than before the hardfork happened.

Most bitcoin whales don't support any of the proposed scaling solutions so far so your scaling fork will end up dumped by tons of coins.

Op's proposal is a multilevel hierarchical sharding schema in which bigger blocks are handled in the top level. As I have debated it extensively above thread there are a lot of issues remained unsolved but I think we need to take every sharding idea as a serious one and figure out a solution for scaling problems eventually, hence hierarchical schemas are promising enough to be discussed and improved, imo.

I would be very curious what Bitcoin's network topology will look like if by some miraculous event, Bitcoin hard forks to bigger blocks and sharding, with consensus. Haha.

Plus big blocks are inherently centralizing the bigger they go. Wouldn't sharding only prolong the issue, and not solve it?

The exchangers are the mini banks yet, maybe worst than Lightning Network, LN is like you put your salary of 1 month and after that you will pay you expenses and you receive back and waste and earn, always the same money, if you loose money you will lose not so much, the actual exchanges are worst, MtGox, Btc-e, Wex, etc they are stealing millions and nobody cares.

Maybe BTC its a little complicated for common citizen and we need that "mini or big banks" to work together.

Off topic, but I thought RNC and all related accounts were banned?  I did have a link, but copying it on a phone is a ballache.

//EDIT:   https://bitcointalksearch.org/topic/m.31377296
RNC admitted to ban evasion and being Anti-Cen there.

They're not.



Caring about short-term fluctuations are usually a sign of a lack of long-term thinking.



Irrelevant to the discussion.



See above, which may also be the reason why some of these posts got deleted, rather than a hidden conspiracy by big crypto.

"Lightning network" == Mini banks

I did warn you all and no the so called new "Off-Block" hubs did not save BTC as we can see from the price.

CPU-Wars, mere 9 transactions per second from 20,000 miners and fees hitting $55 per transaction is what
the BTC code will be remembered for as it enters our history books just like Tulip Mania did in the 1700's

Casino managers are not the best people in the world to take financial advise from and the same goes for the
dis-information moderator here that keeps pressing the delete button here because he hates the truth being exposed.

The issue with your proposal above is that you do not know which transactions to include in which vertical block.  You will not know which transactions take precedence and will introduce a mechanism by which a double spend can occur because a conflicting transaction could be put into two blocks at once.  However, I do think you are thinking in the right direction.

You should check out BlockReduce, which is similar to this idea, but moves transactions in a PoW managed hierarchy to insure consistency of state.  If the manuscript is a bit long, please also check out a presentation I did at University of Texas Blockchain conference.