ethereum/ethereumj#1280
I'd took EIP-1829, everything else is currently available
@chosenegbe
Is there a method to check the number of confirmations (or maybe propagation time) a transaction had before been approved into a block?
Once transaction appears in block, it's 1st confirmation, so I don't understand you question
If the question is, is there a method which logs the time until transaction is included, no, there is no such method. We have only method to estimate average gas price https://github.com/ethereum/ethereumj/blob/develop/ethereumj-core/src/main/java/org/ethereum/listener/RecommendedGasPriceTracker.java
public RawTransactionManager(Web3j web3j, Credentials credentials, byte chainId, int attempts, long sleepDuration) {
super(web3j, attempts, sleepDuration);
this.web3j = web3j;
this.credentials = credentials;
this.chainId = chainId;
}
@chosenegbe I don't understand your question clearly, but if you mean the process of connecting to already discovered nodes, take a look at this part of code https://github.com/ethereum/ethereumj/blob/9bb6d67a73f782d0c3a992fd5fe535224b484cbd/ethereumj-core/src/main/java/org/ethereum/sync/SyncPool.java#L265-L285
In a few words there are two separate processes:
1) Looking up for a new nodes and updating its info in NodeManager
2) Taking some known nodes when we don't have enough connected (see above code), connecting to them and query for data, it's done in SyncManager / SyncPool
plus as we accept incoming connections, some nodes arrive from this source, see PeerServer
thanks for the response @zilm13. To elaborate, lemme give an instance of some naive eclipse attacks. there are eclipse attacks by table poisoning and also by monopolizing the TCP connection. The above attacks mostly target the TCP incoming and outgoing connections. For instance, the TCP connection can be eclipsed if the attacker establishes max-peers incoming TCP connections before the client has a chance to establish any outgoing TCP connections
a trivial countermeasure of the connection monopolization is to enforce an upper limit on the number of incoming TCP connections, forcing clients to make a mix of incoming and outgoing TCP connections
what I'll love to know how/where are peers chosen to define the TCP connection in Ethereumj? maybe some implementation strategies
so that i can log some stats on the connection status (# of incoming/outgoing tcp connections, maybe tcp connection interval, etc.)
SyncPool, for example these lines: https://github.com/ethereum/ethereumj/blob/9bb6d67a73f782d0c3a992fd5fe535224b484cbd/ethereumj-core/src/main/java/org/ethereum/sync/SyncPool.java#L320-L338 where we could drop guys that are connected to our node.TCP attack you've described could be handled only on system level and looks too difficult to be real. Your application just will not be able to open any connection under such kind of attack. And it doesn't guarantee for attacker that its peers could be used for sync, all he could achieve - no sync at all.
All low level TCP settings are in
PeerServer and EthereumChannelInitializer
@chosenegbe we could drop incoming connections, take a look at the same
SyncPool, for example these lines: https://github.com/ethereum/ethereumj/blob/9bb6d67a73f782d0c3a992fd5fe535224b484cbd/ethereumj-core/src/main/java/org/ethereum/sync/SyncPool.java#L320-L338 where we could drop guys that are connected to our node.
TCP attack you've described could be handled only on system level and looks too difficult to be real. Your application just will not be able to open any connection under such kind of attack. And it doesn't guarantee for attacker that its peers could be used for sync, all he could achieve - no sync at all.
All low level TCP settings are inPeerServerandEthereumChannelInitializer
@zilm13 thanks very much, now I get it :)
