Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 981. (Read 4671924 times)
Who owns the address monero.org, someone is developing it
@Vandalay23: what's your project? why do you need all those burn adress? (xmr,nxt,hz,burst +every other one that i did not see)
thanks for your interest
details about the project will be public soon enough.
Burning XMR is a crime against humanity!
@Vandalay23: what's your project? why do you need all those burn adress? (xmr,nxt,hz,burst +every other one that i did not see)
Offering 0.05 BTC to the first one that creates a XMR burn address (only public key needed)
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
I'm pretty sure what you want to have is a provable way to burn funds right?
If so, you need the view key too, otherwise nobody can say "here guys, look I burned X", because there's nothing to look at (due to stealth addresses).
we had a long discussion on this topic already.
if you have 2 addresses, one is a real address (with private key) and one burn address, then you can publish the viewkey of the first one and see all the transactions made from this address to the burn address.
Offering 0.05 BTC to the first one that creates a XMR burn address (only public key needed)
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
I'm pretty sure what you want to have is a provable way to burn funds right?
If so, you need the view key too, otherwise nobody can say "here guys, look I burned X", because there's nothing to look at (due to stealth addresses).
Offering 0.05 BTC to the first one that creates a XMR burn address (only public key needed)
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
Should contain as many consecutive X's as possible and a valid checksum.
Cheers
Code:
http://www.openldap.org/its/index.cgi/?findid=7956
If you compact an empty environment, the copy in meta page 1 is written with the
main DB's root page set to 1, (i.e., pointing to itself) which is invalid.
Attempting to write to the copy triggers an assert.
Workaround - don't try to compact an empty environment... Fix coming shortly.
C:/msys64/home/Reggi/bitmonero/external/db_drivers/liblmdb64/mdb.c:5312: Ass ertion 'root > 1' failed in mdb_page_search()
I'm not sure if this has been discussed before?
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
It's always a matter of tradeoff between convenience and security. If you're worried about large payments, just enter/check the address by hand instead of using open alias.
I'm not sure if this has been discussed before?
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
DNSSEC
I'm not sure if this has been discussed before?
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
OpenAlias is easy and user-friendly (once employed) but isn't there an inherent risk in abuse?
It would be trivial for a cracker to exploit it by changing the xmr recipient_address to one under his control. Another easy exploit is that pretty much any employee at the company which hosts your domain or subdomain can easily change the xmr recipient_address. That is especially handy if the nefarious part (for some reason) knows of large or recurring payments.
hi
how can I change the directory
where to store the database?
how can I change the directory
where to store the database?
there is an option I think --data-dir or something like that (sorry I can't check right now).
Also, if you are on linux you can symlink .bitmonero to somewhere else.
hi
how can I change the directory
where to store the database?
how can I change the directory
where to store the database?
Valid, BUT people will not wait 60 minutes to get that 4.336808e-19 on a quicker blockchain with 1 minute timings.
They will adapt down to awaiting 6 minutes, calling that safe. You see there is some layer 8 problem arising.
They will adapt down to awaiting 6 minutes, calling that safe. You see there is some layer 8 problem arising.
deleting the other post, this is its replacement.
ok here is the formula.
a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else
f(n)=a^(b-1) (im sure this can be simplified but w/e it works)
So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.
and after 60 minutes like bitcoin satoshi client suggests with 1 minute blocks it would be 4.336808e-19.
So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.
ok here is the formula.
a = percentage of the total network hash rate controlled by attacker (expressed in decimal notation)
b = # of blocks
n = likelihood of discovering b # of blocks for a % of total network hashrate before anyone else
f(n)=a^(b-1) (im sure this can be simplified but w/e it works)
So back to our 2 blockchains. If the attacker wants to double-spend and has 25% of the total network hashrate, than his chances of discovering 1 block are 25%. 2 blocks in a row is 12.5%.
|
|
|
|
|
|
|
|
|
|
and after 60 minutes like bitcoin satoshi client suggests with 1 minute blocks it would be 4.336808e-19.
So the point is that there is an inherent advantage to security resulting from fast blocks. As such the acceptable orphan rate would be a reasonable trade off. It wouldn't come from some effort to approach as close to 0 as you can. Once its too high of course single actors get a bigger advantage since they dont have to wait to start mining ontop of their own block. But the preferable trade off would probably be a higher orphan rate than most people think. You would have to develop some models to get a good idea, but probably 5% is totally reasonable.
IMHO the only reason why orphans are bad is because they are rising the efficiency-gap between miners/pools with slower bandwith vs miners/pools with higher ones which would lead to more mining centralization
but please correct me if thats wrong - its just my head trying to figure out p2p
edit: i have seen this happen live with an early p2pool version and bitcoin. p2pool has many many small blocks (they call them shares). my p2pool node was on my server - many have run it at home. i had WAY less orphans and was much more efficient (to a point where i was more efficient than i should be - effectively stealing some btc from people with a bad connection - i stopped mining there then [well i completely stopped mining btc and sold my two remaining gpus]).
but please correct me if thats wrong - its just my head trying to figure out p2p
edit: i have seen this happen live with an early p2pool version and bitcoin. p2pool has many many small blocks (they call them shares). my p2pool node was on my server - many have run it at home. i had WAY less orphans and was much more efficient (to a point where i was more efficient than i should be - effectively stealing some btc from people with a bad connection - i stopped mining there then [well i completely stopped mining btc and sold my two remaining gpus]).
It's not the only reason but it is one reason, and its a huge one. Decentralization is the entire reason for these coins to exist at all. Without that the entire system is a huge waste of resources.
It also increases resource use (especially for lightweight wallets) and makes the network less resilient to failing altogether.
Quote from: https://download.wpsoftware.net/bitcoin/alts.pdf
A common change in altcoins is to increase the block frequency, due to a misunderstanding of the purpose and meaning of transaction confirmations. This increases the frequency of minor blockchain forks (which result in stale blocks and wasted mining power) and also increases the bandwidth and validation costs of non-mining nodes. Both of these tend to increase centralization.
If the block frequency is very high, new blocks will be produced faster than blocks can be transmitted and verified. This destroys consensus since nodes are essentially always seeing competing blockchains in the past. (Remember that consensus time is measured by total blockchain difficulty, roughly, blockheight.) Therefore the first chain that they see will always appear longer than the others, and every node will have a different idea of the best chain.
This happened to feathercoin, which had 60-second blocks. They were unable to achieve distributed consensus, so the network was changed to require developer signatures on all blocks.
If the block frequency is very high, new blocks will be produced faster than blocks can be transmitted and verified. This destroys consensus since nodes are essentially always seeing competing blockchains in the past. (Remember that consensus time is measured by total blockchain difficulty, roughly, blockheight.) Therefore the first chain that they see will always appear longer than the others, and every node will have a different idea of the best chain.
This happened to feathercoin, which had 60-second blocks. They were unable to achieve distributed consensus, so the network was changed to require developer signatures on all blocks.
I'm reasonably sure I discussed this in the LTB podcast, but basically TFT's decision for a 1 minute block time was nonsensical. We don't know why he chose it, but it definitely wasn't based on any form of logic.
Faster block targets were a common gimmick metric for a while in the alt space. TFT chose 1 minute blocks because it he was trying to protect his 80% bytecoin premine and knew he'd cater to the uninformed "faster == better" crowd.
IMHO the only reason why orphans are bad is because they are rising the efficiency-gap between miners/pools with slower bandwith vs miners/pools with higher ones which would lead to more mining centralization
but please correct me if thats wrong - its just my head trying to figure out p2p
edit: i have seen this happen live with an early p2pool version and bitcoin. p2pool has many many small blocks (they call them shares). my p2pool node was on my server - many have run it at home. i had WAY less orphans and was much more efficient (to a point where i was more efficient than i should be - effectively stealing some btc from people with a bad connection - i stopped mining there then [well i completely stopped mining btc and sold my two remaining gpus]).
but please correct me if thats wrong - its just my head trying to figure out p2p
edit: i have seen this happen live with an early p2pool version and bitcoin. p2pool has many many small blocks (they call them shares). my p2pool node was on my server - many have run it at home. i had WAY less orphans and was much more efficient (to a point where i was more efficient than i should be - effectively stealing some btc from people with a bad connection - i stopped mining there then [well i completely stopped mining btc and sold my two remaining gpus]).
Yeah, so
TL;DR
1 minute blox is gude
TL;DR
1 minute blox is gude
I'm reasonably sure I discussed this in the LTB podcast, but basically TFT's decision for a 1 minute block time was nonsensical. We don't know why he chose it, but it definitely wasn't based on any form of logic. Personally, if I had to do it over I'd probably go for a 3 minute block time or so.
We're also not closed to changing Monero's block time to 2 minutes, for eg., and doubling block rewards to match. However, it's low priority at the moment, and will require more research before we put a peg in the sand on that. Possibly the outcome of that research is "the current affect is not drastic, and technology is changing so rapidly that we don't see a need to change it", but we can only know once we get to it:)
I have only a slightly different view. If the decision was nonsensical and wasn't based on logic, then it should just be changed to something sensible at the earliest convenient opportunity. There is no need to do research to undo something that was nonsense and had no research supporting it to begin with. Every opportunity that goes by without fixing it is a decision that is being made without research to continue what TFT started.
Then, once that is out of the way, it certainly makes sense to do research into whether it should be changed again, how to improve things, and so forth.
There is little practical difference at the moment, as it certainly isn't a convenient opportunity to make such a change, with the DB and other more urgent items in play.
After the disappointment (or worse) of the FreeBazaar project, people are going to be understandably more reluctant to give direct donations to even a legitimate project.
Until the crowdfunding features of the Monero forum are up and running I'd suggest finding a trusted escrow to hold the funds and release them upon defined milestones (some could be released at start once a funding goal is achieved).
Until the crowdfunding features of the Monero forum are up and running I'd suggest finding a trusted escrow to hold the funds and release them upon defined milestones (some could be released at start once a funding goal is achieved).
Maybe to save discourse going forward consensus from the community, and especially core devs, could be to loosely only sanction donations if a pre-requisite is met, such as agreement by the project manager to have donations released after met milestones, or that the project manager is already well-known and trusted in the community. Or some such. Otherwise we will keep running into scams, and that could be diminished. When a coredev throws in money it is perceived as sanctioning (i.e. approval) of the project and people behind. I know you are individuals, but...
It looks like Atrides is pulling through, albeit slower than planned though.
Edit: Point:
Edit: You might even be trustworthy, but I will wait till someone vouches for you seeing as you have a Newbie account.
fluffypony donated 50 himself, so i figured that was enough for me to trust. Hope it works out!
Jump to: