My apologizes for not responding in this month, I've been busy in rl and wanted to have the time to answer adequately.

So basing on what emerged by this topic, it seems like there are a several ideas with similarities to my proposal, but the thing that I think differ is the fact that this L2 should work as an aggregator of transactions with the capabilities of transmiting both send/receive addresses and amounts to the Bitcoin Blockchain.

What I actually propose is to create a protocol that aggregate groups (boxes) of transaction instances, made on the layer2, and finalize them by transmitting to the Bitcoin Blockchain. This would reasult in a "many to many" transaction in the main Blockchain, where the many senders and receiver are indicated by the informations stored in the boxes. Thus, the layer2 should be able to deploy transactions on the main blockchain, after gathering all the transaction instances initialized in the l2.
This would result in a much higher number of transaction per second that the network could handle and also a decrease in fees, since every transaction fee would be divided by the many senders aggregated in the boxes by the L2.

One of the main doubts that I have is that, even if there's the option of onetomany transactions and that a single l1 transaction can have multiple inputs, I'm not sure it would be possible to create a transacion with multiple inputs by different public(private) keys.

Hope you'll still be interested in discussing this proposal.

Yes. I let it run a day and it's 29 so I guess I'll just wait. Thanks for the support

I already enabled incoming connection and tried to add the maxconnections command to the conf file but none of the procedures worked. Could it be a matter of bandwidth of my interernet connection?

Thanks all for the replies. It seems like the problem solved by itself. Now the node test on Bitnodes shows green check and I've 5 inbound connections and 10 outbound.

Wondering if I could have more in connections, but it seems like the number is still adjusting at the moment. Outbounds are stable on 10 while inbounds swing from 4 to 6 at the moment.

DHCP Reservation:

Name:   
MyDesktopName
Vendor:   
Unknown Vendor
MAC Address:   MyMacAddress      
IP Address (Reserved):   
myIPaddress
Reserve IP:   
Enabled

Port Forwarding:

Enable Rules:   
Enable
Name:   
BitcoinNode
Interface:   
ATM_PPPoE_0_2
Internal IP:   
myIPaddress ()
(Internal IP must be in the same network segment with LAN IP)
Internal startport:   
8333
Internal endport:   
18333
External startport:   
8333
External endport:   
18333
Protocol Type:   
TCP

Firewall:

step1
protocol type: any
local port: all
remote port: all

step2:
local IP to apply selection:
myIPaddress


No entries. I just tried adding "listen=1" but then deleted it.


I did it but didn't work.

Hi everyone,

I downloaded BitcoinCore to run a full node. I'm already synchronized with the entire blockchain and followed the istructions (https://bitcoin.org/en/full-node#upgrading-bitcoin-core) to enable inbound connections but even after that I can't see any in the node window.

I wanted to ask you some help to figure out where is the problem. I may have done some mistake during the procedure but I couldn't understand where.


In this link there are the screenshots of the various step I made to allow inbound connctions

https://imgur.com/a/pJkNsoO


pic1: DHCP Reservation

pic2: Port Forwarding

pic3: current status of my firewall inbound connections

pic4 and pic5: creation of a new rule


The IP address that I obscured is the same in pic 1, 2 and 5.
The language is italian. I think you just need to know that "Qalsiasy" means "any" or "all".

Also note that I had only two rules in the firewall at the beginning, but after some time (or something I made) it became two.


Thanks for your time.

Buonasera,

Riporto che durante il mio ultimo acquisto di Bitcoin Coinbase ha rifiutato la carta che sono solito utilizzare e con la quale ho effettuato più di una transazione, sempre andata a buon fine. Si tratta di una carta di debito Banca Intesa che non mi ha mai dato problemi con sulla suddetta piattaforma e che aveva fondi più che a sufficienza per effettuare l'operazione.
Infatti ho provato ad effettuare l'acquisto su Binance ed è andato a buon fine.

Qualcuno è informato su quali potrebbero essere i motivi? Non ero a conoscenza di nessun cambio di policy di Banca Intesa per quanto riguarda le operazioni su Coinbase.
Cito di seguito la mail che mi è stata inviata subito dopo l'annullamento della transazione:

"Purtroppo la carta che termina con **************** è stata scollegata dal tuo conto Coinbase perché questo tipo di carta non è più accettato.
Ciò può accadere quando cambiano le leggi sulla valuta digitale vigenti nel Paese o le regole dei singoli istituti finanziari.

Puoi ritentare l'acquisto con la stessa carta. Se l'esito della convalida è ancora negativo, prova con un altro metodo di pagamento."

Golden cross finally.

Yesterday the 50SMA crossed the 200SMA for the first time since September 2021. This could be the beginning of a bull run. By the way it's legit to assume that markets will be, at least at the beginning, cautious, since, as Edwardard recalled, a death cross on the weekly frame is also coming, for the first time of the history of Bitcoin.
We don't know which of the two events will impose itself on the other, they might even cancel each other out in a crab action.

Macro is not exactly by the side of bulls, with interest rates that, even with a slower ratio, keep raising and a strong American job market (something very positive in the overall, obviously), that will allow FED to adopt strict policies for a longer period of time.
Forecasts on inflation are good by the way, with milder prospects of a recession. Even if there won't be a QE comeback, economic stability, decreasing inflation and, sooner or later, decreasing interest rates could favor risk-on investments in the mid-long term.

I think the moment that will determine whether or not we are on a bull run will be the FED pivot, wich is something that will inevitably happen no later than Q3 2024.

That said we need to observe the outcomes of the upcoming death cross. In order to avoid it there should be a sudden, great pump capable of inverting the trend.

Basing on the behaviour of the price during the last golden cross, what could happen is a retracement to 19/20k that could last for the remaining days of February, until the beginning of a steady up action by the fall of february/beginning of March, leading to the conversion of the various resistance levels to support levels, pointing to the last ATH.

Another scenario is the comeback to pre-FTX crisis levels for an indefinite period of time (until macro gets better).

Last, markets could just ignore the signals of one of the two crosses, leading both to a new low (as bears predict) or directly to a new important pump from this week.

https://bitcoinbounties.org/

This site from coinkite provide an aggregation of the bounties currently opened for the development of the Bitcoin environment.
I'm sure a lot of you already knew but maybe others don't.

This is a brilliant idea to optimize the efforts carried on by the community.

- Reposted from here https://bitcointalk.org/index.php?topic=5436542.msg61644842#msg61644842

https://bitcoinbounties.org/

This site from coinkite provide an aggregation of the bounties currently opened for the development of the Bitcoin environment.
I'm sure a lot of you already knew but maybe others don't.

This is a brilliant idea to optimize the efforts carried on by the community.

Your guess is right, I missed that information. However, as I'm seeing it right now, the positive correction of the last weeks slowed the fall of the short-term MA and a consistent uptrend, maybe carried by FOMC positive announcements on interest rates/inflation/recession, could help dodging the dead cross but yeah, if the golden cross seems to be forming, the dead cross seems to actually happen so I guess we'll see.

Very interesting times to observe by the way.

https://imgur.com/oQI8mJb

Imgur link (still newbie, no copper membership) to a screenshoot of the chart confronting 50 days SMA and 200 days SMA, showing a steady approach of the 50 MA to the 200 MA that could happen in the first half of February, giving a quick look at the slope of both the curves.
Not an meticulous work methodology, but the main point I'd like to underline is that we didn't appreciated such an approximation since September 2021, which is when the last golden cross occurred, leading to the November 2021 ≈70k$ ATH.

What do you think about it and the quality of SMA crossover monitoring as a TA tool?

Perfectly explanatory post!

I would like to add just a little info that helped me a lot to frame out the analytic functioning of inflation/deflation through monetary policy, that is the notion provided by the Quantity theory of money.

It basically relies on a simple mathematical law, that in its exemplified form is known as equation of exchange:


Where

M is the money circulating supply,
V is the velocity of money, or the frequency of transactions in a given period of time(basically how fast money flows),
P is the average price level,
Q is the quantity of transactions of produced goods in a given period of time.

The left-hand member of the equation is the money supply (MS = MxV), while the right-handed one is the money demand (MD = PxQ) and the relation between the two basically states that in an economy all the actors cannot spend more than all the actors produce (gain).

Assuming V and T as constants, (the velocity of circulation of a simple medium of exchange (V) depends on consumers habits, and the quantity of goods (Q) is produced in a situation of full employment -Fisher-), if the monetary policy maker decides to inject money in the system, alias printing new money (increasing the value of M value in the equation), in order to maintain the law (equation), prices must necessarily increase proportionally (Increasing the P value in the equation).

This increase of P is what we call inflation.

If instead of increasing M, we decrease it (destroy money), in order to keep the law valid prices (P) must decrease as well, proportionally. That is what we call deflation.

This model gives an analytic reason on why abundance of money leads to inflation, while scarcity leads to deflation, and why Bitcoin tends to gain purchasing power (facing decreasing supply over time, thus decreasing purchasing price levels for goods, that is to say higher value for itself), while FIATs tends to loose it (facing increasing supply, thus increasing price levels for goods, or lower value for itself).

Also, I think that a "box" system would be able to collect more transactions than a channel, since channels collect a series of transaction between the same two entities diluted in time, while a box collect a group of one-to-one instances of payment simultaneously.

Moreover, micro-transaction are usually one-shot events, so not reiterated in time. That makes overkilling to use channels for that for most of use cases.

Yeah. I'm thinking more about a system that doesn't need channels at all together with something that can optimize mining output without sacrifice security.
This way transactions becomes more flexible and easy for users, that won't need to know nothing new about how to make an online payment.
Since scaling is led by adoption, so I'm more for a product that fits everyday people rather than something set as standard by companies and exchanges, so let's say "top-down".

Yeah, it has the analogies and differences that you mentioned with CoinJoin, which I didn't know before so thank you. The purpose is not mixing, nor specifically raise the privacy level, even if it could be quite easy to implement such a functionality I guess even if I'm not a fan of absolute secrecy in Bitcoin and think that the "default" system gives users the most reasonable level of privacy.

As for the rest yeah, you got it right. The transaction instances should be delivered to blockchain for validation only when the boxes are full.
The current problem of PoW protocol is that a lot of transactions can't find a block to be inscribed in and has to wait a very variable amount of time to find one.
This L2 network could do this work instead of the blockchain. Boxes are quite like blocks in their functioning, but boxes has different dimensions so that it's easier for the system to allocate transaction instances. Merging transactions in one, so that the the blockchain will see just one big one, is the part inspired by Lightning Network, but yeah, it overcomes the need to find a multisig address.

Also, if you want to make just one single transaction with someone, you don't need to open a channel, with all that implies, nor "hope" that the receiver address is in the channel network of someone that is in your network.
LN still remain the best scaling solution available right now imho, but user-side, I there could be some improvements.

This is a layer 2 concept on the Bitcoin Blockchain that I elaborated from the functioning assumptions of Lighning Network, and would be an improvement of it. I would like to hear your considerations on that, mainly on feasibility and preservation of security granted by on-chain validation system.

I'm an economist and web developer, not a cryptographer.

This concept aims at solving the well-known scalability issues affecting Bitcoin Blockchain, that is the main brake to BTC Blockchain mass adoption.
Every constructive consideration or rebuttal are well accepted. I just want to humbly share with you the idea and see if it's possible to obtain some interesting hint for the qualitative development of the Proof-of-Work Blockchain technology in a mass adoption-oriented perspective.

So here's the idea:

The main goal is to overcome at the capacity of the approx. average of 7 transactions per second that the current Bitcoin Blockchain is able to perform. I focused on the output quality of these 7 transactions per second, rather than a way to improve the number with "brute-force" or algorithm optimization (honestly, I wouldn't even be able to do that).

The L2 should work like this:

Users willing to make a transaction in Bitcoin, acting on layer 2, would eventually open a transaction instance. This instance would comprehend the address sending currency, the address reciving currency, and the import of the transaction.

This instance would be send to a "Box". Boxes should have various setted maximum dimensions basing on the order of magnitude of the import. We are still on layer 2 and no real transaction still happened.
When the sum of the instances imports reach the capacity level of the so called box, this box will be used to create a block on the blockchain. Basically, one box is equal to a single transaction in the Layer 1 blockchain's block. Thus, a single transaction on the block will contain a lot of smaller transactions, collected by the L2 system.

We are now in layer 1.
When the sums of the boxes dimensions in the block will match the maximum dimension allowed for a block, (1MB, or 4MB, after SegWit), the block is created and ready for validation.
For security reasons, a log, containing all the sending addresses, paired with relative recivers, could be attached to the block (maybe in the head of the block as metadata?), so that there would be specific tracking of all the transactions composing boxes even on-chain.

So transaction instances go to boxes. Boxes go to Blocks. Blocks are validated on the blockchain.

At this point, the amount of Bitcoin reported in boxes inside the block is sent to the reciving addresses by the layer 2 system, off-chain, basing on the log that tracks send/receive addresses.
For this step, the L2 should maybe provide two addresses, one sending the amount in the boxes (transactions) stored in the block (after collecting all the instances to fill the box), and one reciving it (before the L2 split the import between the receiver addresses -users-, off-chain).

- Why boxes of different dimensions?

In order to aggregate efficiently transaction instances, these are stored in boxes that takes some time to be filled. The more transactions instances takes places in the L2 system, the fastest boxes are filled and the sooner the block recives transactions (boxes) for validation (scalability).
More boxes can be filled simultaneusly in the shortest amount of time possible, since every transaction instance will immediately find a "free" box, regardless the dimension of the traded import.

- Blocks still takes approx. 10 minutes on average to be added to the blockchain.

In this time window, the L2 could provide the possibility of delete the transaction instance, something we can consider user-friendly. This would be possible only until the block enter validation process.
Also in this time window, L2 could show imports of transaction with the "account balance - available balance" logic.
This means that until the block isn't validated and added to the blockchain the sending address will still have property on the amount of currency committed in the transaction instance, displayed as account balance but not as available balance. Same for the reciving address, unless the fact that the latter won't have property of that amount, not yet. This is maybe the weakest part of the concept from a security perspective. Waiting to ear your considerations on that.

Assuming the number of transaction instances very (sufficiently) high, which is something desirable, filling boxes would take a few seconds and the transfer would be, at least nominally, immediate on the L2 environment.

Bitcoin Blockchain would still create a block every 10 mins on average, but the blocks would be representative of a much higher number of actual transactions, working smarter rather than stronger.

I would really like to hear your considerations on that. What is wrong, what is good (if there's something good actually), what could eventually be improved? Is this valuable for further considerations and maybe prototyping?

Thanks for your time and attention, This is my first post. Hope I did everything the right way and post on the right section.

I originally posted this on the Bitcoin discussion section: https://bitcointalk.org/index.php?topic=5413582.0

This is a layer 2 concept on the Bitcoin Blockchain that I elaborated from the functioning assumptions of Lighning Network, and would be an improvement of it. I would like to hear your considerations on that, mainly on feasibility and preservation of security granted by on-chain validation system.

I'm an economist and web developer, not a cryptographer.

This concept aims at solving the well-known scalability issues affecting Bitcoin Blockchain, that is the main brake to BTC Blockchain mass adoption.
Every constructive consideration or rebuttal are well accepted. I just want to humbly share with you the idea and see if it's possible to obtain some interesting hint for the qualitative development of the Proof-of-Work Blockchain technology in a mass adoption-oriented perspective.

So here's the idea:

The main goal is to overcome at the capacity of the approx. average of 7 transactions per second that the current Bitcoin Blockchain is able to perform. I focused on the output quality of these 7 transactions per second, rather than a way to improve the number with "brute-force" or algorithm optimization (honestly, I wouldn't even be able to do that).

The L2 should work like this:

Users willing to make a transaction in Bitcoin, acting on layer 2, would eventually open a transaction instance. This instance would comprehend the address sending currency, the address reciving currency, and the import of the transaction.

This instance would be send to a "Box". Boxes should have various setted maximum dimensions basing on the order of magnitude of the import. We are still on layer 2 and no real transaction still happened.
When the sum of the instances imports reach the capacity level of the so called box, this box will be used to create a block on the blockchain. Basically, one box is equal to a single transaction in the Layer 1 blockchain's block. Thus, a single transaction on the block will contain a lot of smaller transactions, collected by the L2 system.

We are now in layer 1.
When the sums of the boxes dimensions in the block will match the maximum dimension allowed for a block, (1MB, or 4MB, after SegWit), the block is created and ready for validation.
For security reasons, a log, containing all the sending addresses, paired with relative recivers, could be attached to the block (maybe in the head of the block as metadata?), so that there would be specific tracking of all the transactions composing boxes even on-chain.

So transaction instances go to boxes. Boxes go to Blocks. Blocks are validated on the blockchain.

At this point, the amount of Bitcoin stored in boxes inside the block is sent to the reciving addresses by the layer 2 system, off-chain, basing on the log that tracks send/receive addresses.
For this step, the L2 should maybe provide two addresses, one sending the amount in the boxes (transactions) stored in the block (after collecting all the instances to fill the box), and one reciving it (before the L2 split the import between the receiver addresses -users-, off-chain).

- Why boxes of different dimensions?

In order to aggregate efficiently transaction instances, these are stored in boxes that takes some time to be filled. The more transactions instances takes places in the L2 system, the fastest boxes are filled and the sooner the block recives transactions (boxes) for validation (scalability).
More boxes can be filled simultaneusly in the shortest amount of time possible, since every transaction instance will immediately find a "free" box, regardless the dimension of the traded import.

- Blocks still takes approx. 10 minutes on average to be added to the blockchain.

In this time window, the L2 could provide the possibility of delete the transaction instance, something we can consider user-friendly. This would be possible only until the block enter validation process.
Also in this time window, L2 could show imports of transaction with the "account balance - available balance" logic.
This means that until the block isn't validated and added to the blockchain the sending address will still have property on the amount of currency committed in the transaction instance, displayed as account balance but not as available balance. Same for the reciving address, unless the fact that the latter won't have property of that amount, not yet. This is maybe the weakest part of the concept from a security perspective. Waiting to here your considerations on that.

Assuming the number of transaction instances very (sufficiently) high, which is something desirable, filling boxes would take a few seconds and the transfer would be, at least nominally, immediate on the L2 environment.

Bitcoin Blockchain would still create a block every 10 mins on average, but the blocks would be representative of a much higher number of actual transactions, working smarter rather than stronger.

I would really like to hear your considerations on that. What is wrong, what is good (if there's something good actually), what could eventually be improved? Is this valuable for further considerations and maybe prototyping?

Thanks for your time and attention, This is my first post. Hope I did everything the right way and post on the right section.